机器人故障恢复方法、装置、设备和计算机可读存储介质

技术领域

本发明涉及机器人领域，特别涉及一种机器人故障恢复方法、装置、设备和计算机可读存储介质。

背景技术

机器人的应用场合越来越广泛，餐厅、医院、商超、仓库等都能看到各种机器人忙碌的“身影”。机器人属于高度精密的智能系统，除了机器人本体，一个机器人还包括各种传感器件等硬件单元以及在此基础之上的软件程序。只有硬件单元和硬件程序的功能均正常发挥，机器人才能正常运作。

机器人正常运作是理想状态，现实是机器人仍然会产生故障——硬件和/或软件的故障。现有恢复机器人故障的方法主要依赖于人工，通常是人工发现机器人故障后，将故障信息向服务器上传。服务器收到故障信息后提供故障恢复方案传回，人工按照传回的故障恢复方案对故障的机器人进行恢复。

然而，上述现有恢复机器人故障的方法存在时间差，例如，人工不是能够及时发现故障，服务器传回故障恢复方案也可能较晚，若网络状况不佳，则可能更晚才能收到故障恢复方案；另一方面，还要依赖于人工的操作，这给机器人用户带来效率较低的不良体验。

发明内容

本申请提供一种机器人故障恢复方法、装置、设备和计算机可读存储介质，以及时、高效地恢复机器人的故障。

一方面，本申请提供了一种机器人故障恢复方法，包括：

实时监测故障事件端口；

当监测到来自所述故障事件端口的故障事件时，通过所述故障事件的触发来源分析机器人所发生故障的故障类型，所述故障类型包括所述机器人的硬件发生故障和软件出现异常；

若所述故障类型为所述机器人的硬件发生故障，则通过自动开启所述机器人的硬件以恢复所述机器人的故障；

若所述故障类型为所述机器人的软件出现异常，则通过重置所述机器人的状态以恢复所述机器人的故障。

另一方面，本申请提供了一种机器人故障恢复装置，包括：

监测模块，用于实时监测故障事件端口；

分析模块，用于当监测到来自所述故障事件端口的故障事件时，通过所述故障事件的触发来源分析机器人所发生故障的故障类型，所述故障类型包括所述机器人的硬件发生故障和软件出现异常；

第一故障恢复模块，用于若所述故障类型为所述机器人的硬件发生故障，则通过自动开启所述机器人的硬件以恢复所述机器人的故障；

第二故障恢复模块，用于若所述故障类型为所述机器人的软件出现异常，则通过重置所述机器人的状态以恢复所述机器人的故障。

第三方面，本申请提供了一种设备，所述设备包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述机器人故障恢复方法的技术方案的步骤。

第四方面，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述机器人故障恢复方法的技术方案的步骤。

从上述本申请提供的技术方案可知，当监测到来自故障事件端口的故障事件时，通过故障事件的触发来源分析机器人所发生故障的故障类型，若故障类型为机器人的硬件发生故障，则通过自动开启机器人的硬件以恢复机器人的故障，若故障类型为机器人的软件出现异常，则通过重置机器人的状态以恢复机器人的故障。由于机器人发生的故障无非是硬件故障或软件故障，而无论是哪种故障，都可以通过计算机程序自动予以恢复，因此，相对于现有技术需要人工发现和处理机器人的故障，本申请的技术方案在发现机器人的故障方面更为及时，在处理机器人的故障方面效率更高，因而亦能给予机器人用户更好的使用体验。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的机器人故障恢复方法的流程图；

图2是本申请实施例提供的机器人故障恢复装置的结构示意图；

图3是本申请实施例提供的设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本说明书中，诸如第一和第二这样的形容词仅可以用于将一个元素或动作与另一元素或动作进行区分，而不必要求或暗示任何实际的这种关系或顺序。在环境允许的情况下，参照元素或部件或步骤(等)不应解释为局限于仅元素、部件、或步骤中的一个，而可以是元素、部件、或步骤中的一个或多个等。

在本说明书中，为了便于描述，附图中所示的各个部分的尺寸并不是按照实际的比例关系绘制的。

本申请提出了一种机器人故障恢复方法，可应用于机器人，该机器人可以是在餐厅作业的机器人，例如，传菜机器人，也可以是在医疗场所，例如医院作业的送药机器人，还可以是在仓库等场所作业的搬运机器人，等等。如附图1所示，机器人故障恢复方法主要包括步骤S101至S104，详述如下：

步骤S101：实时监测故障事件端口。

在本申请实施例中，故障事件端口是由机器人的中央处理单元开放给数据定时监测装置和软件异常捕获装置的接口，故障事件端口连接至数据定时监测装置和软件异常捕获装置，而这两种装置即是故障事件的触发来源。中央处理器单元可以实时监测故障事件端口的电平或逻辑值，通过电平或逻辑值的变化来判断是否产生了故障事件，例如，若故障事件端口由低电平跳到高电平，或者其逻辑值由逻辑“0”变为逻辑“1”，则产生了故障事件；当然，亦可以是相反的变化，例如，若故障事件端口由高电平跳到低电平，或者其逻辑值由逻辑“1”变为逻辑“0”，则产生了故障事件，本申请对此不做限定。

步骤S102：当监测到来自故障事件端口的故障事件时，通过故障事件的触发来源分析机器人所发生故障的故障类型，其中，故障类型包括机器人的硬件发生故障和软件出现异常。

由于机器人所发生故障的类型不同，需要采用不同的故障恢复策略，因此，当监测到来自故障事件端口的故障事件时，通过故障事件的触发来源来分析机器人所发生故障的故障类型，其中，故障类型包括机器人的硬件发生故障和软件出现异常。此处，机器人的硬件包括机器人本体搭载的各种传感器(例如，激光雷达)和图像采集设备(例如，相机)等，而软件既可以机器人的操作系统等系统软件，又可以是支持传感器、图像采集设备的应用程序。如前所述，故障事件端口用于传递故障事件，该故障事件可以使用高电平或者逻辑“1”表示(亦可以使用低电平或逻辑“0”表示)，其可以由数据定时监测装置或软件异常捕获装置触发，即，故障事件的触发来源既可以是数据定时监测装置，又可以是软件异常捕获装置。因此，在本申请一个实施例中，通过故障事件的触发来源分析机器人所发生故障的故障类型可以是：若故障事件由数据定时监测装置触发，则确定故障类型为机器人的硬件发生故障；若故障事件由软件异常捕获装置触发，则确定故障类型为机器人的软件出现异常。

作为本申请一个实施例，上述故障事件由数据定时监测装置触发可以是：监测机器人的硬件产生的业务数据送达数据定时监测装置的时间，若从最近一次收到机器人的硬件产生的业务数据计时起，超过预设阈值后尚未收到该硬件产生的业务数据，则触发故障事件。此处的预设阈值可以根据经验值来确定，亦可以根据统计数据来确定，例如，统计历史上机器人的硬件每次产生的业务数据送达数据定时监测装置的最长时间，将该最长时间作为预设阈值。

作为本申请另一实施例，上述故障事件由数据定时监测装置触发可以是：监测每个心跳监测周期到来时是否产生心跳报文响应包，若在心跳监测周期到来时没有监测到心跳报文响应包文，则触发故障事件，其中，心跳报文响应包为硬件与硬件产生的业务数据的接收方(以下简称业务数据接收方)之间一方对另一方发送的心跳报文的响应，例如，机器人的硬件向业务数据接收方发送心跳报文，则业务数据接收方收到该心跳报文后，理应向机器人的硬件发送一个心跳报文响应包作为对其收到机器人的硬件发送心跳报文的响应。正是因为机器人的硬件与业务数据接收方具有这种发送心跳报文和反馈心跳报文响应包的机制，并且心跳报文或心跳报文响应包是按照周期发送，因此，数据定时监测装置可以利用这一机制，监测每个心跳监测周期(该监测周期亦是机器人的硬件与业务数据接收方发送心跳报文或心跳报文响应包的周期)到来时是否产生心跳报文响应包；若在心跳监测周期到来时没有监测到心跳报文响应包文，则触发故障事件。

需要说明的是，上述实施例中“在心跳监测周期到来时没有监测到心跳报文响应包文”的“没有监测到心跳报文响应包文”并非绝对。考虑到在心跳监测周期到来时虽然没有监测到心跳报文响应包文，但这种情形可能是受偶然因素的影响，并非是机器人的硬件真的发生故障，因此，上述若在心跳监测周期到来时没有监测到心跳报文响应包文，则触发故障事件可以是：若在心跳监测周期到来在当前心跳响应超时时间内没有监测到心跳报文响应包文，则判定心跳响应超时；当心跳响应超时次数达到预设次数阔值时，触发故障事件，其中，当前心响应跳超时时间可由以下方式设定：每次判定在当前心跳响应超时时间内收到心跳报文响应包时，将预设心跳超时时间作为下一次判断是否心跳响应超时的当前心跳响应超时时间；每次出现心跳响应超时，选择不同于当前心跳响应超时时间的自定义心跳响应超时时间，作为下一次判断是否心跳响应超时的当前心跳响应超时时间，其中，上述选择不同于当前心跳响应超时时间的自定义心跳响应超时时间可是为：在预设范围内随机选自定义心跳响应超时时间，或者，在当前心跳响应超时时间基础上递增，将递增后的心跳响应超时时间作为自定义心跳响应超时时间。如此，可以最大程度上确保最后一次判断使用的心跳响应超时时间为随机值，从而降低误判机器人的硬件发生故障的概率。

在本申请一个实施例中，上述故障事件由软件异常捕获装置触发可以是：预先配置异常捕获机制；若通过预先配置的拦截器检测到异常捕获机制抛出异常，则触发故障事件。上述实施例中，异常捕获机制可以是try-catch拦截机制，其通过try语句进行异常检测。若try语句中检测到异常，则将异常通过throw语句抛出至拦截器，该拦截器检测到异常，触发故障事件。考虑到异常数据(例如，异常发生路径、异常发生时间和异常发生对应的日志信息等)的数量庞杂，只对异常数据简单处理，不利于对机器人故障的分析。因此，在本申请一个实施例中，上述“预先配置异常捕获机制，若通过预先配置的拦截器检测到异常捕获机制抛出异常，则触发故障事件”之后还包括：若通过预先配置的拦截器检测到异常捕获机制中有异常抛出，则单独获取机器人的软件运行时产生的异常数据，根据任意一个异常数据中包括的至少一种异常特征信息，对机器人的软件运行时产生的异常数据进行聚类合并，其中，异常特征信息包含异常发生时间、异常所在应用的名称、异常接口名、异常调用接口名、异常IP地址和异常描述信息中的一种或任意组合，而单独获取机器人的软件运行时产生的异常数据可以是在机器人的软件运行时产生的数据中，将正常的业务数据与异常数据分离，单独获取这些异常数据。通过对机器人的软件运行时产生的异常数据进行聚类合并，生成各种维度的聚类合并后数据，使数据针对性较强，为后续的数据分析与故障点定位提供支持。

步骤S103：若故障类型为机器人的硬件发生故障，则通过自动开启机器人的硬件以恢复机器人的故障。

在本申请一个实施例中，上述步骤S103的实现可以是：若故障类型为机器人的硬件发生故障，则重启一次发生故障的硬件，若重启发生故障的硬件失败，则再次重启发生故障的硬件，直至成功重启发生故障的硬件或者再次重启的次数超过预设次数。在后一种情况中，即再次重启的次数超过预设次数，则限制机器人执行任务。以机器人的硬件是激光雷达为例，说明上述实施例的技术方案。具体地，可以通过获取机器人连接的所有USB设备，读取生产此设备的供应商的标识。若能够从USB设备中找到激光雷达的供应商标识，则说明激光雷达在线，可以尝试重新开启一次该激光雷达。在开启该激光雷达成功后，开始监测是否可以接收到有效的业务数据。若能够接收到有效的业务数据，则判断激光雷达重启成功，机器人可以继续执行任务。若重启激光雷达失败，则再次尝试重启，其中，可以设定固定的尝试时间或者尝试次数(例如，假设可以重复尝试5秒钟或重复尝试5次，等等)。若超过重启次数或者预设时间，则定义为激光雷达重启失败，限制机器人不能继续执行任务。

在本申请另一实施例中，上述步骤S103的实现还可以是：若故障类型为机器人的硬件发生故障，则对发生故障的硬件进行阻隔，开启备用硬件，并将分配给发生故障的硬件的业务重新分配给该备用硬件，其中，备用硬件为与发生故障的硬件具有同等业务处理能力的硬件，对发生故障的硬件进行阻隔可以是停止发生故障的硬件工作、阻止其与其他硬件的之间的交互等方式实现，进一步地，还可以预设阻隔次数，当初次对发生故障的硬件进行阻隔的操作失败，在预设的隔离次数内重试阻隔的操作。上述实施例在无法重启或修复发生故障的硬件的情形下，充分利用机器人内搭载的与发生故障的硬件具有同等业务处理能力的硬件，从而仍然可以使得机器人恢复正常的任务。

步骤S104：若故障类型为机器人的软件出现异常，则通过重置机器人的状态以恢复机器人的故障。

具体而言，在故障类型为机器人的软件出现异常时，通过重置机器人的状态以恢复机器人的故障一般可以是通过软件重启或初始化机器人的状态，来尝试恢复机器人的故障。

需要说明的是，无论是机器人的硬件发生故障，还是机器人的软件出现异常，只要确认机器人是真正发生故障，则机器人中的中央处理单元向其伺服机构发送停止运行指令，使得机器人在当前行走路线上停止前行，即需要结束或者暂停一切的有关行走的任务，以降低危险。只有在确认机器人的故障恢复后，才可以重新下达或者恢复任务，让机器人继续执行任务。

从上述附图1示例的机器人故障恢复方法可知，当监测到来自故障事件端口的故障事件时，通过故障事件的触发来源分析机器人所发生故障的故障类型，若故障类型为机器人的硬件发生故障，则通过自动开启机器人的硬件以恢复机器人的故障，若故障类型为机器人的软件出现异常，则通过重置机器人的状态以恢复机器人的故障。由于机器人发生的故障无非是硬件故障或软件故障，而无论是哪种故障，都可以通过计算机程序自动予以恢复，因此，相对于现有技术需要人工发现和处理机器人的故障，本申请的技术方案在发现机器人的故障方面更为及时，在处理机器人的故障方面效率更高，因而亦能给予机器人用户更好的使用体验。

请参阅附图2，是本申请实施例提供的一种机器人故障恢复装置，可以包括监测模块201、分析模块202、第一故障恢复模块203和第二故障恢复模块204，详述如下：

监测模块201，用于实时监测故障事件端口；

分析模块202，用于当监测到来自故障事件端口的故障事件时，通过故障事件的触发来源分析机器人所发生故障的故障类型，其中，故障类型包括机器人的硬件发生故障和软件出现异常；

第一故障恢复模块203，用于若故障类型为机器人的硬件发生故障，则通过自动开启机器人的硬件以恢复机器人的故障；

第二故障恢复模块204，用于若故障类型为机器人的软件出现异常，则通过重置机器人的状态以恢复机器人的故障。

可选地，附图2示例的装置中，故障事件端口与数据定时监测装置和软件异常捕获装置连接，分析模块202可以包括第一确定单元和第二确定单元，其中：

第一确定单元，用于若故障事件由数据定时监测装置触发，则确定故障类型为机器人的硬件发生故障；

第二确定单元，用于若故障事件由软件异常捕获装置触发，则确定故障类型为机器人的软件出现异常。

可选地，上述第一确定单元可以包括第一监测单元和第一触发单元，其中：

第一监测单元，用于监测机器人的硬件产生的业务数据送达数据定时监测装置的时间；

第二确定单元，用于若从最近一次收到机器人的硬件产生的业务数据计时起，超过预设阈值后尚未收到机器人的硬件产生的业务数据，则触发故障事件。

可选地，上述第一确定单元可以包括第二监测单元和第二触发单元，其中：

第二监测单元，用于监测每个心跳监测周期到来时是否产生心跳报文响应包，其中，心跳报文响应包为硬件与硬件产生的业务数据的接收方之间一方对另一方发送的心跳报文的响应；

第二触发单元，用于若在心跳监测周期到来时没有监测到心跳报文响应包，则触发故障事件。

可选地，上述第二确定单元可以包括预配置单元和第三触发单元，其中：

预配置单元，用于预先配置异常捕获机制；

第三触发单元，用于若通过预先配置的拦截器检测到异常捕获机制抛出异常，则触发故障事件。

可选地，附图2示例的装置还可以包括获取模块和聚合模块，其中：

获取模块，用于若通过预先配置的拦截器检测到异常捕获机制中有异常抛出，则单独获取软件运行时产生的异常数据，其中，异常数据中的任一个包括至少一种异常特征信息；

聚合模块，用于根据异常特征信息，对机器人的软件运行时产生的异常数据进行聚类合并。

可选地，上述第一故障恢复模块203可以包括第一重启单元和第二重启单元，其中：

第一重启单元，用于若故障类型为机器人的硬件发生故障，则重启一次发生故障的硬件；

第二重启单元，用于若重启发生故障的硬件失败，则再次重启发生故障的硬件，直至成功重启发生故障的硬件或者再次重启的次数超过预设次数。

可选地，上述第一故障恢复模块203可以包括阻隔单元和开启单元，其中：

阻隔单元，用于若故障类型为机器人的硬件发生故障，则对发生故障的硬件进行阻隔；

开启单元，用于开启备用硬件，并将分配给发生故障的硬件的业务重新分配给备用硬件，其中，备用硬件为与发生故障的硬件具有同等业务处理能力的硬件。

从以上技术方案的描述中可知，当监测到来自故障事件端口的故障事件时，通过故障事件的触发来源分析机器人所发生故障的故障类型，若故障类型为机器人的硬件发生故障，则通过自动开启机器人的硬件以恢复机器人的故障，若故障类型为机器人的软件出现异常，则通过重置机器人的状态以恢复机器人的故障。由于机器人发生的故障无非是硬件故障或软件故障，而无论是哪种故障，都可以通过计算机程序自动予以恢复，因此，相对于现有技术需要人工发现和处理机器人的故障，本申请的技术方案在发现机器人的故障方面更为及时，在处理机器人的故障方面效率更高，因而亦能给予机器人用户更好的使用体验。

图3是本申请一实施例提供的设备的结构示意图。如图3所示，该实施例的设备3主要包括：处理器30、存储器31以及存储在存储器31中并可在处理器30上运行的计算机程序32，例如机器人故障恢复方法的程序。处理器30执行计算机程序32时实现上述机器人故障恢复方法实施例中的步骤，例如图1所示的步骤S101至S104。或者，处理器30执行计算机程序32时实现上述各装置实施例中各模块/单元的功能，例如图2所示监测模块201、分析模块202、第一故障恢复模块203和第二故障恢复模块204的功能。

示例性地，机器人故障恢复方法的计算机程序32主要包括：实时监测故障事件端口；当监测到来自故障事件端口的故障事件时，通过故障事件的触发来源分析机器人所发生故障的故障类型，其中，故障类型包括机器人的硬件发生故障和软件出现异常；若故障类型为机器人的硬件发生故障，则通过自动开启机器人的硬件以恢复机器人的故障；若故障类型为机器人的软件出现异常，则通过重置机器人的状态以恢复机器人的故障。计算机程序32可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器31中，并由处理器30执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序32在设备3中的执行过程。例如，计算机程序32可以被分割成监测模块201、分析模块202、第一故障恢复模块203和第二故障恢复模块204(虚拟装置中的模块)的功能，各模块具体功能如下：监测模块201，用于实时监测故障事件端口；分析模块202，用于当监测到来自故障事件端口的故障事件时，通过故障事件的触发来源分析机器人所发生故障的故障类型，其中，故障类型包括机器人的硬件发生故障和软件出现异常；第一故障恢复模块203，用于若故障类型为机器人的硬件发生故障，则通过自动开启机器人的硬件以恢复机器人的故障；第二故障恢复模块204，用于若故障类型为机器人的软件出现异常，则通过重置机器人的状态以恢复机器人的故障。

设备3可包括但不仅限于处理器30、存储器31。本领域技术人员可以理解，图3仅仅是设备3的示例，并不构成对设备3的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如计算设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器30可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器31可以是设备3的内部存储单元，例如设备3的硬盘或内存。存储器31也可以是设备3的外部存储设备，例如设备3上配备的插接式硬盘，智能存储卡(Smart MediaCard，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，存储器31还可以既包括设备3的内部存储单元也包括外部存储设备。存储器31用于存储计算机程序以及设备所需的其他程序和数据。存储器31还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即，将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述装置中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个非临时性计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，机器人故障恢复方法的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤，即，实时监测故障事件端口；当监测到来自故障事件端口的故障事件时，通过故障事件的触发来源分析机器人所发生故障的故障类型，其中，故障类型包括机器人的硬件发生故障和软件出现异常；若故障类型为机器人的硬件发生故障，则通过自动开启机器人的硬件以恢复机器人的故障；若故障类型为机器人的软件出现异常，则通过重置机器人的状态以恢复机器人的故障。其中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。非临时性计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读内存(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，非临时性计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，非临时性计算机可读介质不包括电载波信号和电信信号。以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。