CN112536819A - 一种故障处理方法、装置、机器人及存储介质 - Google Patents

Abstract

本申请适用于服务机器人技术领域，提供了一种故障处理方法、装置、机器人及系统，所述方法包括：监测机器人的硬件工作状态、软件工作状态和运动状态信息；根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型，采用与所述故障类型对应的处理机制处理所述异常故障。本申请可以解决相关技术中机器人安全性不高的技术问题。

Description

一种故障处理方法、装置、机器人及存储介质

技术领域

本申请属于机器人技术领域，尤其涉及一种机器人的故障处理方法、装置、机器人及计算机可读存储介质。

背景技术

机器人是一种半自主或全自主工作的智能机器，具有感知、决策、执行等基本特征，可以辅助甚至替代人类完成危险、繁重、复杂的工作，提高工作效率与质量。

近年来，服务机器人市场保持较快的增长速度。各种服务机器人和工业机器人等日益增多。针对机器人设计的控制方案也是层出不穷。但是，机器人自动运动控制的核心是需要做到安全，而与安全紧密相关的运动参数是机器人运动的速度和加速度。所以，无论上层具体的控制方案多么复杂，最终下发的速度一定要确保机器人安全可靠。因此，亟需一种用于机器人速度控制的后端优化方法。

目前，机器人行业在做自动控制时，可能会加入速度优化和安全保障的措施。但是，表现力度有限，依然无法让机器人在一个复杂的环境中自由运动。一旦上层控制方案失效，机器人运动的速度将会发生急剧不可控制的变化，存在一定的危险性。

发明内容

本申请实施例提供了一种机器人的故障处理方法、装置、机器人及计算机可读存储介质，可以解决相关技术中机器人安全性不高的技术问题。

第一方面，本申请实施例提供了一种机器人的故障处理方法，包括：

监测机器人的硬件工作状态、软件工作状态和运动状态信息；

根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型，采用与所述故障类型对应的处理机制处理所述异常故障。

在第一方面的实施例中，兼顾了机器人三大方面的防护。从硬件本身的状态属性，到软件控制层的功能状态，以及到最后一层，运动本身信息，同时进行数据监控，全方位有效的监控机器人可能出现的各种异常故障，保障更全面，提高了机器人的安全性。此外，应对机器人出现各种不同的异常故障时，有对应的合理控制机制，保证机器人在发生异常故障时，可以限制自身的速度大小，保障机器人和周围环境的安全。

在第一方面的一可能实现方式中，所述根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型，采用与所述故障类型对应的处理机制处理所述异常故障，包括：

所述根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生硬件异常故障、软件异常故障或运动异常故障，采用与所述硬件异常故障、所述软件异常故障或所述运动异常故障对应的处理机制处理所述机器人的异常故障。

在第一方面的一可能实现方式中，所述根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生硬件异常故障、软件异常故障或运动异常故障，采用与所述硬件异常故障、所述软件异常故障或所述运动异常故障对应的处理机制处理所述机器人的异常故障，包括：

若根据所述硬件工作状态，确定所述机器人的第一硬件发生硬件异常故障，则确定所述硬件异常故障所属的硬件故障等级，采用与所述硬件故障等级对应的处理机制处理所述异常故障；

若根据所述软件工作状态，确定所述机器人的第一软件发生软件异常故障，则确定所述软件异常故障所属的软件故障等级，采用与所述软件故障等级对应的处理机制处理所述异常故障；

若根据所述运动状态信息，确定所述机器人发生运动异常故障，则采用与所述运动异常故障对应的处理机制处理所述运动异常故障。

在第一方面的一可能实现方式中，所述运动状态信息包括底盘速度执行延时、底盘速度执行大小和行走累加里程。

在第一方面的一可能实现方式中，所述根据所述运动状态信息，确定所述机器人发生运动异常故障，包括：

确定所述机器人的所述底盘速度执行延时、所述底盘速度执行大小和所述行走累加里程中的至少一个，不满足预设条件，则确定所述机器人发生运动异常故障。

在第一方面的一可能实现方式中，所述采用与所述运动异常故障对应的处理机制处理所述运动异常故障，包括：

控制所述机器人的电机以最高加速度降速到零，并控制所述机器人的所有硬件锁死。

在第一方面的一可能实现方式中，还包括：

上报所述异常故障到与所述机器人进行通信连接的电子设备，或，控制所述机器人针对所述异常故障进行提示。

第二方面，本申请实施例提供了一种机器人的故障处理装置，包括：

监测单元，用于监测机器人的硬件工作状态、软件工作状态和运动状态信息；

故障诊断单元，用于根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型，

故障处理执行单元，用于采用与所述故障类型对应的处理机制处理所述异常故障。

在第二方面的一可能实现方式中，所述故障处理装置，还包括：

警示执行单元，用于上报所述异常故障到与所述机器人进行通信连接的电子设备，或，控制所述机器人针对所述异常故障进行提示。

第三方面，本申请实施例提供了一种机器人，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的故障处理方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的故障处理方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在机器人上运行时，使得机器人执行上述第一方面所述的故障处理方法。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

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

图1是本申请一实施例提供的故障处理方法的流程示意图；

图2是本申请一实施例提供的判断底盘速度执行大小合理性的方法流程示意图；

图3是本申请一实施例提供的判断底盘速度执行延时合理性的方法流程示意图；

图4是本申请一实施例提供的判断行走累加里程合理性的方法流程示意图；

图5是本申请一实施例提供的故障处理装置的结构示意图；

图6是本申请一实施例提供的故障处理方法所适用于的机器人的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

目前，机器人的自动控制方案中会加入安全保障措施，例如，对导航控制层输出的速度，做简单的滤波处理，再下发到电机。这种安全保障措施没有进行很好的场景保护和异常状态检测保护。

因此，本申请实施例提供一种机器人的故障处理方法，包括：监测机器人的硬件工作状态、软件工作状态和运动状态信息；根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型；采用与所述故障类型对应的处理机制处理所述异常故障。

本申请实施例提供的故障处理方法，兼顾了机器人三大方面的防护。从硬件本身的状态属性，到软件控制层的功能状态，以及最后一层，运动本身信息的同时进行数据监控分析，全方位有效的监控机器人可能出现的各种异常故障，保障更全面，提高了机器人的安全性。

本申请实施例提供的技术方案主要是应对机器人出现各种不同的异常故障时，有对应的合理控制机制，从而进行速度制约。保证机器人在发生异常故障时，可以限制自身的速度大小，保障机器人和周围环境的安全。本申请实施例提供的故障处理方法可以应用于各种服务类机器人自主导航控制方案最末端的速度优化控制方案。

由于处理器是速度的最终下发端，一切紧急的速度急停都需要经过它的处理。因此，本申请实施例中，检测和处理机器人的三方面的异常故障，并生成对应的控制指令由处理器来完成。

本申请一些实施例中，机器人完成决策控制，加入了后端的速度保护控制。如果没有任何硬件上的异常或者外部人员的强行干涉，可以正常的完成工作任务。

本申请一些实施例中，详细描述了处理器如何确定各种异常故障，以及对应各种异常故障如何生成控制速度，以使得处理器生成的速度是最权威最安全的，实现了准确无误，不误判。

下面对本申请实施例提供的一种故障处理方法进行详细描述。

图1示出了本申请提供的一种故障处理方法的示意性流程图。该方法由故障处理装置执行。该故障处理装置配置于机器人，该故障处理装置可由软件和/或硬件实现。作为示例而非限定，该方法可以应用于各类机器人。如图1所示，该方法包括步骤S110至S120，各个步骤的实现过程及原理如下。

S110，监测机器人的硬件工作状态、软件工作状态和运动状态信息；

在本申请实施例中，兼顾了机器人三大方面的防护。监测机器人的硬件工作状态、软件工作状态和运动状态信息。

机器人包括多种硬件，例如：电机、驱动器、主控板、电源、主雷达、测雷达、红外、声呐、相机、显示屏、灯等。监测机器人各种硬件的工作状态。

机器人包括多种软件，例如：路径规划器软件、速度控制软件、任务指派软件、监控状态软件、定位软件等。监测机器人各种软件的工作状态。

因为机器人能否安全运作，全在运动层面，如果机器人是静止不动的将可以避免各种安全问题。运动状态的监测与处理，是机器人控制当中比较重要一环。本申请实施例对机器人运动状态信息进行监测与处理，可以及时有效的拦截机器人软件和硬件故障触发的异常问题，防止机器人跑飞乱撞，或者失控陷入危险场景。

在本申请一实现方式中，运动状态信息包括：底盘速度执行延时、底盘速度执行大小和行走累加里程等。

在本申请一实现方式中，在机器人启动时就开始执行本申请实施例的故障处理方法，从而在机器人工作的过程中，持续的监测机器人三方面的数据，确定各类异常故障，并进行对应的控制处理。

在本申请另一实现方式中，在机器人启动后，检测到用户执行预设触发操作，开始执行本申请实施例的故障处理方法，例如用户一键触发机器人执行故障处理方法。需要说明的是，预设触发操作可以由用户在机器人上触发。还需要说明的是，预设触发操作可以包括但不限于触控操作、语音控制操作、或光标控制操作等。本申请对此均不予限制。

在本申请另一实现方式中，在机器人启动后，接收到来自电子设备的触发指令，开始执行本申请实施例的故障处理方法，例如用户在电子设备执行预设触发操作，电子设备发送触发指令到机器人，机器人根据所述触发指令开始执行故障处理方法。需要说明的是，预设触发操作可以由用户在与机器人通信连接的电子设备上触发。还需要说明的是，预设触发操作可以包括但不限于触控操作、语音控制操作、或光标控制操作等。本申请对此均不予限制。

S120，根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型，采用与所述故障类型对应的处理机制处理所述异常故障。

在步骤S110，监测机器人各种硬件的硬件工作状态，各种软件的软件工作状态以及各种运动状态信息等三方面的信息，然后，在步骤S120，根据这三方面的信息确定机器人发生异常故障的故障类型，采用与故障类型对应的处理机制处理所述异常故障。

在本申请一些实施例中，监测机器人各种硬件的硬件工作状态，各种软件的软件工作状态以及各种运动状态信息，确定是哪方面的信息发生异常故障，从而确定发生异常故障的故障类型。

作为本申请一实现方式，步骤S110，包括：根据硬件工作状态、软件工作状态和运动状态信息，确定机器人发生硬件异常故障、软件异常故障或运动异常故障，采用与硬件异常故障、软件异常故障或运动异常故障对应的处理机制处理机器人的异常故障。

具体地，步骤S110，包括：

若根据所述硬件工作状态，确定所述机器人的第一硬件发生硬件异常故障，则确定所述硬件异常故障所属的硬件故障等级，采用与所述硬件故障等级对应的处理机制处理所述异常故障；

若根据所述软件工作状态，确定所述机器人的第一软件发生软件异常故障，则确定所述软件异常故障所属的软件故障等级，采用与所述软件故障等级对应的处理机制处理所述异常故障；

若根据所述运动状态信息，确定所述机器人发生运动异常故障，则采用与所述运动异常故障对应的处理机制处理所述异常故障。

在本申请一些实施例中，预先对硬件进行分类，针对每类硬件的异常故障，设置对应的硬件故障等级。此外，预设硬件故障等级与处理机制的对应关系，从而可以采用与硬件故障等级对应的处理机制处理所述异常故障。

示例性地，根据机器人硬件功能的重要性，预先将硬件分为三大类。三类硬件的异常故障，对应三类硬件故障等级。预设每一类硬件故障等级对应的控制机制，从而采用与所述硬件故障等级对应的处理机制处理所述异常故障。

一类硬件故障，也可以称作核心硬件故障，主要是指机器人能够驱动机器人正常运动的核心元件。比如，电机、驱动器、主控板、电源、主雷达等发生异常故障。如果，这些硬件发生故障，机器人会出现当场崩溃或者完全失控。

与一类硬件故障对应的处理机制为：当确定所述机器人发生一类硬件故障，如果机器人中央控制器正常，那么软件层将立即下发速度零，控制电机急停。同时，通知底层控制端，进行电气抱死，防止机器人运动。在一些实施例中，还可以触发机器人的警示灯开启，和/或，向电子设备发出故障信号，从而上报工作人员，等待维修人员处理。

二类硬件故障，也可以称作辅助功能硬件故障，主要是指机器人在正常运作时，来保证运行过程中的安全，具有辅助功能的传感器发生异常故障。比如，测雷达、红外、声呐、相机等。这些传感器的功能不是必须要有的，只是在一些特殊场合下，进行辅助安全防范，保证机器人能够更精确的定位，并更好的避开障碍物。

与二类硬件故障对应的处理机制：当确定机器人发生二类硬件故障，控制机器人结束目前正在运行的所有任务，定位附件的或最近的停靠点，并将速度限制在预设速度以下到达停靠点。停靠点可以为预设的停靠点或任一靠边位置；预设速度，例如0.4m/s至0.6m/s中的任一速度，优选为0.5m/s。控制机器人低速靠近停靠点，避免误撞到障碍物时，发生严重的碰撞行为。最后在机器人到达停靠点后，下发速度零，控制机器人停止在停靠点。在一些实施例中，还可以触发机器人发出故障信号，和/或，上报故障信息到工作人员的电子设备，等待维修。

三类硬件故障，也可以称作其他功能硬件故障，主要是指机器人身上安装的用于宣传、显示、或人机交互的显示屏或者起警示作用的灯带等硬件发生异常故障。这些硬件的功能主要是宣传广告、美观、警示等作用。他们损坏后，不影响机器人正常使用。

与三类硬件故障对应的处理机制：当确定机器人发生三类硬件故障，机器人正常工作，此时不做速度处理。当完成当前的工作任务后，机器人回到任务等待点时，可以控制机器人发出故障信号，和/或，上报故障信息到工作人员的电子设备。任务等待点可以为预设的位置，为机器人完成当前工作任务，等待下一个工作任务时所处的位置。在一些实施例中，若工作人员远程操作，允许机器人继续工作，则消除故障信号，机器人继续工作。否则，机器人停止在任务等待点，等待维修。也就是说，若获取到机器人继续工作指示，则根据该指示消除机器人的故障信号，继续工作。若未获取到机器人继续工作指示，则控制机器人停止在任务等待点，等待工作人员维修。

需要说明的是，在一些实施例中，硬件异常故障可以在显示屏进行提示。

在本申请一些实施例中，预先对软件进行分类，针对每类软件的异常故障，设置对应的软件故障等级。此外，预设软件故障等级与处理机制的对应关系，从而可以采用与软件故障等级对应的处理机制处理所述异常故障。

示例性地，根据机器人软件功能的特点，预先将软件分成四大类，从而四大类的软件的异常故障，对应四类软件故障等级。预设每一类软件故障等级对应的控制机制，从而采用与所述软件故障等级对应的处理机制处理所述异常故障。

A类错误，也可以称作严重错误，主要是指直接影响到机器人运动和工作的软件发生异常故障。直接影响到机器人运动和工作的软件，一般指核心控制软件，比如路径规划器软件、速度控制软件、任务指派软件等。一旦这类软件出错机器人将彻底无法运动。在本申请一些实施例中，若根据这类软件中任一软件的软件工作状态，确认该软件的软件功能状态为挂掉，则确定发生A类错误。

与A类错误对应的处理机制：当确定机器人出现A类错误后，可以确定机器人已经无法再继续工作或者运动，此时，处理器会下发速度零，控制机器人立即停下，留在原地，等待现场的工作人员来处理。在本申请一些实施例中，确定机器人出现A类错误后，可以在显示界面对A类错误进行显示提示，也可以发出A类错误的语音提示，可以上报到工作人员的电子设备，等到工作人员来处理。

B类错误，也可以称作异常错误，主要是指一些监控状态软件的发生异常故障。此类错误一旦发生，机器人会出现暂时性的无法执行当前任务，或者无法执行其他功能任务等。比如，机器人乘坐电梯时，发现与电梯通讯异常，机器人将无法完成坐电梯的任务。再比如，配送任务完成后，联系呼叫客户端异常等。或者其他的有监控交互性质的功能。这些功能异常只会影响局部的任务完成，不会影响到机器人正常运动。在本申请一些实施例中，若根据这类软件中任一软件的软件工作状态，确认该软件的软件功能状态为异常，则确定发生B类错误。

与B类错误对应的处理机制：当出现B类错误之后，控制机器人结束当前正在执行的任务，标记为执行失败的任务，依次执行任务队列中的其他任务后，若其他任务执行失败，也进行标记。在完成任务队列中的其他任务后，导航到起始点，控制机器人断电并重启，重启后，重复之前执行失败的任务。如果某一任务失败三次，机器人将放弃该任务，上报异常故障到工作人员的电子设备，等待工作人员处理，处理过程当中不做速度处理。在本申请一些实施例中，确定机器人出现B类错误后，可以在显示界面对B类错误进行显示提示，可以不发出B类错误的语音提示，可以上报到工作人员的电子设备，等到工作人员来处理。

C类错误，也可以称作偶发错误，主要是指运动过程中机器人因为某种异常干扰引起的软件错误，比如，定位软件发现位置丢失。位置丢失有可能是被行人估计挪动造成。但机器人可以通过小距离的运动，来将位置重新找回，所以问题不太严重。还有一种就是，机器人被故意干扰现在在原地超过1分钟，目标执行软件会触发目标执行失败，重新规划新的目标路线。如果此时机器人可以摆脱困境，机器人将继续完成任务。

与C类错误对应的处理机制：当出现C类错误以后，机器人会自动尝试其他方式来摆脱现有的困境；如果可以恢复到正常模式，机器人将继续工作，不上报工作人员；如果，C类错误无法消除，将升级为B类错误，错误内容依旧是C类，处理方式按照B类方式处理，请参考B类处理机制，过程当中不做速度处理。在本申请一些实施例中，确定机器人出现C类错误后，可以在显示界面不对C类错误进行显示提示，可以发出C类错误的语音提示，可以不上报到工作人员的电子设备。

D类错误，也可以称作警示错误，主要是指机器人的软件功能状态为正常，发生提示性错误的异常故障。比如机器人在走的过程当中，被暂时的阻挡或者被拍了紧急开关，此时机器人会立刻上报D类错误，和/或，发出异常故障语言提示，提示周围的人帮忙处理。D类错误，主要是应对短时间内的功能错误，时间过长，将触发其他更高一级错误。比如，机器人被阻挡不超过1分钟，会不断发出D类错误的异常故障语言提示，和/或，上报D类错误，提示周围的人让一让；如果机器人被阻挡超过一分钟，将触发C类错误。

与D类错误对应的处理机制：当出现D类错误以后，语音提示周围环境，帮忙处理当前异常，等待摆脱异常状态。超时摆脱不了，将错误升级到C类，进行相应处理，过程当中不做速度处理。在本申请一些实施例中，确定机器人出现D类错误后，可以在显示界面不对D类错误进行显示提示，可以发出D类错误的语音提示，可以上报或不上报到工作人员的电子设备。

在本申请一些实施例中，监测机器人的多个运动状态信息，判断每个运动状态信息是否满足预设条件，若其中至少一个不满足预设条件，则确定所述机器人发生运动异常故障，采用与所述运动异常故障对应的处理机制处理运动异常故障。

示例性地，监测机器人的底盘速度执行延时、底盘速度执行大小和行走累加里程这三个运动状态信息，分别判断他们是否各自满足预设条件，若其中一个不满足预设条件，则确定机器人发生运动异常故障，采用运动异常故障对应的处理机制处理运动异常故障。

具体地，如图2所示，为判断底盘速度执行大小是否满足第一预设条件的流程示意图。第一预设条件为针对底盘速度执行大小设置的预设条件，为经验值。判断底盘速度执行大小是否满足第一预设条件，也就是确认底盘速度执行大小的合理性。如果不合理，则说明机器人运动异常故障，需要进行对应的处理。流程如下所述：

第1步，设定两个计数器，第一计数器T_Num和第二计数器N_Num，初始化两个计数器，初始值设为0，T_Num＝0，N_Num＝0。

第2步，获取机器人当前决策层下发速度：cmd_vel。

第3步，获取当前底盘执行层反馈的速度：odom_vel。

第4步，比对cmd_vel与odom_vel的大小，判断两者的差值是否满足预设条件，例如，判断两者的差值是否小于或等于预设阈值error_vel，或者，判断两者的偏差是否小于预设阈值error_vel，或者，判断两者的差值是否在0至预设阈值error_vel的范围内。两者的差值可以用两者做差后的绝对值来表示。预设阈值error_vel是针对当前决策层下发速度和当前底盘执行层反馈的速度的差值设置的阈值，为经验值。

如果是，则确认底盘速度执行大小合理。跳转到第1步，继续执行。此时，还可以输出底盘速度执行大小合理的提示。

如果不是，则继续往下执行第5步。

第5步，此时，第一计数器的值加1，T_Num＝T_Num+1。

第6步，判断第一计数器T_Num的值是否等于第一预设值，第一预设值例如15至30以内的任一数值，优选为20。

如果等于第一预设值，则继续进行下一步，第7步；

如果不等于第一预设值，则跳转到第3步。

第7步，此时，第二计数器的值加1，第一计数器的值清零，N_Num＝N_Num+1，T_Num＝0。

第8步，判断第二计数器的值N_Num的值是否等于第二预设值，第二预设值例如4至7以内的任一数值，优选为5。

如果等于第二预设值，则确认底盘速度执行大小不合理，确认机器人发生运动异常故障，第二计数器的值清零，N_Num＝0。跳转到第1步，继续执行。此时，还可以输出底盘速度执行大小不合理或机器人发生运动异常故障的提示等。

如果不等于第二预设值，则跳转到第3步。

具体地，如图3所示，为判断底盘速度执行延时是否满足第二预设条件的流程示意图。第二预设条件为针对底盘速度执行延时设置的预设条件，为经验值。判断底盘速度执行延时是否满足第二预设条件，也就是确认底盘速度执行延时的合理性。如果不合理，则说明机器人运动异常故障，需要进行对应的处理。流程如下所述：

第1步，设定两个计数器，第一计数器T_Num和第二计数器N_Num，初始化两个计数器，初始值设为0，T_Num＝0，N_Num＝0。

第2步，获取机器人当前决策层下发速度：cmd_vel。

第3步，获取当前底盘执行层反馈的速度：odom_vel。

第4步，比对cmd_vel与odom_vel的大小，判断两者的差值是否满足预设条件，例如，判断两者的差值是否小于或等于预设阈值error_vel，或者，判断两者的偏差是否小于预设阈值error_vel，或者，判断两者的差值是否在0至预设阈值error_vel的范围内。两者的差值可以用两者做差后的绝对值来表示。预设阈值error_vel是针对当前决策层下发速度和当前底盘执行层反馈的速度的差值设置的阈值，为经验值。

如果是，则确认底盘速度执行延时合理。跳转到第1步，继续执行。此时，还可以输出底盘速度执行延时合理的提示。

如果不是，则继续往下执行第5步。

第5步，此时，第一计数器的值加1，T_Num＝T_Num+1。

第6步，判断第一计数器T_Num的值是否大于或等于第一预设值，第一预设值例如15至30以内的任一数值，优选为20。

如果大于或等于第一预设值，则继续进行下一步，第7步；

如果小于第一预设值，则跳转到第3步。

第7步，此时，第二计数器的值加1，N_Num＝N_Num+1。

第8步，判断第二计数器的值N_Num的值是否等于第二预设值，第二预设值例如4至7以内的任一数值，优选为5。

如果等于第二预设值，则确认底盘速度执行延时不合理，确认机器人发生运动异常故障，第二计数器的值清零，N_Num＝0，第一计数器的值清零，T_Num＝0。跳转到第1步，继续执行。此时，还可以输出底盘速度执行延时不合理或机器人发生运动异常故障的提示等。

如果不等于第二预设值，则跳转到第3步。

需要说明的是，在判断底盘速度执行大小的合理性，和判断底盘速度执行延时的合理性时，都使用了两个计数器，用于判断底盘速度执行大小的合理性的两个计数器，与用于判断底盘速度执行延时的合理性的两个计数器为不相同的计数器。此处示例为了描述的方便，在两个合理性的判断方案中均使用了第一计数器和第二计数器用于各自方案中的命名区分。应理解，出现在两个合理性的判断方案中的第一计数器不为同一个计数器，第二计数器也不为同一个计数器。

具体地，如图4所示，为判断行走累加里程是否满足第三预设条件的流程示意图。第三预设条件为针对行走累加里程设置的预设条件，为经验值。判断行走累加里程是否满足第三预设条件，也就是确认行走累加里程的合理性。如果不合理，则说明机器人运动异常故障，需要进行对应的处理。流程如下所述：

第1步，设定截取路程的时间T＝2s。截取路程的时间是针对结束时间和开始时间的差值设置的阈值，为经验值。

设定里程计理论里程之和cmd_dis_sum，并初始化，初始值设为0，cmd_dis_sum＝0，

设定里程计实际里程之和odom_dis_sum，并初始化，初始值设为0，odom_dis_sum＝0。

第2步，记录当前开始时间：Time_start＝time(0)。

第3步，获取当前决策层下发速度：cmd_vel。

第4步，根据控制周期dt，计算当前控制周期内机器人运动的理论里程cmd_dis_dt。

第5步，获取当前底盘执行层反馈的速度：odom_vel。

第6步，根据控制周期dt，计算当前控制周期内机器人运动的实际里程odom_dis_dt。

第7步，更新里程计的理论里程之和：cmd_dis_sum＝cmd_dis_sum+cmd_dis_dt；

更新里程计的实际里程之和：odom_dis_sum＝odom_dis_sum+odom_dis_dt。

第8步，记录当前结束时间：Time_end＝time(0)。

第9步，判断结束时间和开始时间的差值是否达到T，即判断Time_end-Time_start＝T是否成立？

如果成立，Time_start＝Time_end，执行下一步，第10步；

如果不成立，跳转到第3步。

第10步，判断cmd_dis_sum与odom_dis_sum的偏差值error_dis是否大于cmd_dis_sum*0.3+0.5？两者的差值可以用两者做差后的绝对值来表示。

如果大于，则确认行走累加里程不合理，确认机器人发生运动异常故障。此时，还可以输出行走累加里程不合理或机器人发生运动异常故障的提示等。

如果不大于，则确认行走累加里程合理，确认机器人未发生运动异常故障。此时，还可以输出行走累加里程合理的提示等。

第11步，跳转到第1步，继续执行。

对以上三个运动状态信息的合理性判断，当出现任一个不合理的现象时，及时的做出速度保护。具体地，控制所述机器人的电机以最高加速度降速到零，并控制所述机器人的所有硬件锁死。

在本申请实施例中，监测到不合理的运动异常故障之后，直接在控制系统末端——最后的速度控制软件，进行速度保护，不受其他任何约束，直接控制电机的速度状态。此时，以机器人允许的最高加速度，将机器人速度限制到零，发送机器人硬件速度锁死指令，使机器人彻底停在原地不动。此外，还可以在显示界面对运动异常故障进行显示提示，也可以发出运动异常故障的语音提示，可以上报到工作人员的电子设备，等到工作人员来处理。也就是说上报现场和远程的工作人员，发出警报危险信号，等待工作人员即时做出处理反馈。

本申请实施例提供的故障处理方法，兼顾了机器人三大方面的防护。从硬件本身的状态属性，到软件控制层的功能状态，以及最后一层，运动本身信息的同时进行数据监控分析，全方位有效的监控机器人可能出现的各种异常故障，保障更全面，提高了机器人的安全性。

此外，针对机器人有可能出现的各种异常问题，该故障处理方法都会配合实际情况，采取相应的处理策略，最后制定一套有效的控制和输出方案，使机器人在异常状态的情形下，也能够高效安全的尽可能的完成相应的任务。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对应于上文实施例所述的故障处理方法，图5示出了本申请实施例提供的故障处理装置的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图5，该故障处理装置包括：

监测单元51，用于监测机器人的硬件工作状态、软件工作状态和运动状态信息；

故障诊断单元52，用于根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型，

故障处理执行单元52，用于采用与所述故障类型对应的处理机制处理所述异常故障。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

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

本申请实施例提供的故障处理方法可以应用于机器人，机器人包括服务机器人，工业机器人等。本申请实施例对机器人的具体类型不作任何限制。

图6为本申请一实施例提供的一种机器人的结构示意图。如图6所示，该实施例的机器人6包括：至少一个处理器60(图6中仅示出一个)、存储器61以及存储在所述存储器61中并可在所述至少一个处理器60上运行的计算机程序62，所述处理器60执行所述计算机程序62时实现本申请实施例提供的各个故障处理方法实施例中的步骤。或实现本申请实施例提供的各个故障处理装置实施例中各个单元的功能。

所述机器人6可包括，但不仅限于，处理器60、存储器61。本领域技术人员可以理解，图6仅仅是机器人的举例，并不构成对机器人的限定，机器人可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备、电机、驱动器、主控板、电源、雷达、相机、红外、声呐、灯、警报等。

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

所述存储器61在一些实施例中可以是所述机器人6的内部存储单元，例如机器人6的硬盘或内存。所述存储器61在另一些实施例中也可以是所述机器人6的外部存储设备，例如所述机器人6上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器61还可以既包括所述机器人6的内部存储单元也包括外部存储设备。所述存储器61用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例等所述计算机程序的程序代码等。所述存储器61还可以用于暂时地存储已经输出或者将要输出的数据。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在机器人上运行时，使得机器人执行时实现可实现上述各个方法实施例中的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/机器人的任何实体或装置、记录介质、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random AccessMemory，RAM)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

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

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

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

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

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种机器人的故障处理方法，其特征在于，包括：

监测机器人的硬件工作状态、软件工作状态和运动状态信息；

根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型，采用与所述故障类型对应的处理机制处理所述异常故障。

2.如权利要求1所述的故障处理方法，其特征在于，所述根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型，采用与所述故障类型对应的处理机制处理所述异常故障，包括：

所述根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生硬件异常故障、软件异常故障或运动异常故障，采用与所述硬件异常故障、所述软件异常故障或所述运动异常故障对应的处理机制处理所述机器人的异常故障。

3.如权利要求2所述的故障处理方法，其特征在于，所述根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生硬件异常故障、软件异常故障或运动异常故障，采用与所述硬件异常故障、所述软件异常故障或所述运动异常故障对应的处理机制处理所述机器人的异常故障，包括：

若根据所述硬件工作状态，确定所述机器人的第一硬件发生硬件异常故障，则确定所述硬件异常故障所属的硬件故障等级，采用与所述硬件故障等级对应的处理机制处理所述异常故障；

若根据所述软件工作状态，确定所述机器人的第一软件发生软件异常故障，则确定所述软件异常故障所属的软件故障等级，采用与所述软件故障等级对应的处理机制处理所述异常故障；

若根据所述运动状态信息，确定所述机器人发生运动异常故障，则采用与所述运动异常故障对应的处理机制处理所述运动异常故障。

4.如权利要求3所述的故障处理方法，其特征在于，所述运动状态信息包括底盘速度执行延时、底盘速度执行大小和行走累加里程。

5.如权利要求4所述的故障处理方法，其特征在于，所述根据所述运动状态信息，确定所述机器人发生运动异常故障，包括：

确定所述机器人的所述底盘速度执行延时、所述底盘速度执行大小和所述行走累加里程中的至少一个，不满足预设条件，则确定所述机器人发生运动异常故障。

6.如权利要求4所述的故障处理方法，其特征在于，所述采用与所述运动异常故障对应的处理机制处理所述运动异常故障，包括：

控制所述机器人的电机以最高加速度降速到零，并控制所述机器人的所有硬件锁死。

7.如权利要求1至6任一项所述的故障处理方法，其特征在于，还包括：

上报所述异常故障到与所述机器人进行通信连接的电子设备，或，控制所述机器人针对所述异常故障进行提示。

8.一种机器人的故障处理装置，其特征在于，包括：

监测单元，用于监测机器人的硬件工作状态、软件工作状态和运动状态信息；

故障诊断单元，用于根据所述硬件工作状态、软件工作状态和运动状态信息，确定所述机器人发生异常故障的故障类型，

故障处理执行单元，用于采用与所述故障类型对应的处理机制处理所述异常故障。

9.一种机器人，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的故障处理方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的故障处理方法。

Images