我们总结了一整套方法论，终于不再为故障排查没有进展落泪了！

本文约3873个字，预计阅读时间10分钟
 

故障排查的“方法论”

经验分享篇

机器人是一个综合性比较高的产品，涉及多种学科的知识，如果没有受过系统的机器人培训，面对故障时很可能一点头绪都没有。

我们在机器人行业有些年头了，自己做机器人，集成机器人，现场调试机器人，同时还负责给客户们做技术支持。这么多年过去了我们也算是有了些设备调试、排错的经验，所以想写下来给刚进入机器人行业的研究者以及同学们参考，帮助大家少走些弯路。

不要着急归因

故障发生时，很容易犯的一个错误是，不对现象进行仔细的排查，凭经验直接下结论。确实凭经验有时可以快速的解决问题，但是一旦方向错误了，花费的时间可能比按照标准方法排查还要长。所以我的建议是要严格遵循故障排查的基本原则，凭借经验加速故障排查过程，而非省略某些过程。当你确认了现象与故障点之间的因果关系后，再进行后续的步骤。

注意：紧盯系统给出的故障提示

很多人会因为错误码太多，或者看不懂英文而忽视系统给出的错误，凭借自己的推测进行排查。这是不可取的，系统错误信息往往包含故障的关键原因，有时候凭借故障码手册可以快速的定位到问题。所以不论系统抛出的故障信息多么繁杂，一定要仔细查阅。

寻找故障的规律

有些故障可能是间歇性的、时有时无的。找到故障的规律，对问题复现以及测试都是非常有利的。规律可能体现在时间维度上，比如在固定的时间点，或者固定的时间间隔；也有可能体现在其它维度上，比如机器人的关节在某个特定角度下，或者特定的运动模式下，或者在特定的环境中会出现故障。在寻找规律时要仔细思考故障发生的时与平时正常运行时的差别，任何细节都不放过。

构建复现故障的最小系统

有效的故障排除法是在故障发生时，逐步关闭没有问题的模块，直至找到复现故障的最小系统形态。我在开头也说过，机器人是一个复杂度很高的产品，由多个组件多个软件模块构成。要明白的是，不同的模块出问题时，机器人的现象有可能一致的，起码在经验不丰富的时候是很难分辨出来到底是什么地方出了问题。所以我们要通过削减系统的方式，排除掉正常的功能模块，将故障点凸显出来，为后续的故障分析做准备。

要有质疑一切的心态

不怕系统发生大问题，就怕系统发生小问题。原因是大问题的特征极其明显，故障排查非常好做，但是小问题的根源总是藏的非常深，很难找到。在故障发生后，要对所有技术点进行质疑和验证，尤其是那些看似不容易出错的地方。有人可能会说这样做太浪费时间了，但是要明白，如果真的是这些不容易出错的地方发生了错误而你没察觉，调试的时间可能要涨好几倍。所以充分的质疑是有必要的。推荐的做法是，对最小复现系统中理应正常的模块进行快速的验证，然后再排查那些不太容易排查的模块，这其实也是在帮助我们进一步获得复现故障的最小系统。

等效替换与极限测试

最常用的故障排查方式是等效替换与极限测试。等效替换指的是将你认为可能出问题的地方进行等效替换，然后观察整个系统是否恢复了预期。替换包括实物的替换，软件版本的替换，以及使用假的合理数据进行模拟仿真。极限测试指的是在一些现象不是很明显时，可以通过赋予系统参数极值的方法，放大某些现象从而寻找规律。不过使用时要注意极值带来的系统的不稳定，所以要做提前好保护措施，例如架空机器人，建立隔离区，以及准备多种紧急停止的方案等，避免造成其它损坏。

系统性的知识体系

上面提到的故障排查方法其实都是方法论，决定方法论执行好坏的是个人的知识体系是否健全。故障排查考察的是一个人对系统的认知的完整度，你是否明白系统是如何构成的，是否知道各部分之间的关联形式，以及你是否知道系统结构的优势劣势，都会对你排查故障起决定性作用。我们公司在对客户进行售后培训时，经常会和客户强调不论研究重点是什么，都应当系统性的了解机器人相关知识，了解机器人的构造、控制模型以及各种限制，这不仅仅是为了排查故障，更是为了让客户充分发挥机器人的优势服务于他们自己的研究。

寻求帮助的技巧

如果问题已经超出了你能解决的能力，或者你需要在短时间内完成排查，那么你可能会通过多种渠道寻求他人的帮助，比如在一些网站上发帖或者直接联系设备商寻求帮助。需要注意的是这些渠道的沟通往往缺乏时效性。为了尽快的解决问题，沟通的技巧非常的重要。如果你经常访问Github或者StackOverflow之类的网站，你会发现他们提供了很好的提问模板，请尽量遵从它们，这非常有利于减少沟通次数。原因其实和上述描述的技巧有非常大的关系，如果你能准确的描述故障的现象和规律、使用设备的环境与方法以及你做过的尝试，其他人能够快速跟进到故障排查工作中，而非从头开始做起。而且描述的越准确，越有利于帮助者判断你的技术能力，进而使用你能听懂的方式进行沟通。如果你有过消费产品售后咨询的经验，你会发现他们最一开始问的问题都非常的基础，甚至会让你觉得他们把人当傻瓜看，但是这是避免出现“听不懂”以及“误判”现象的最好的方法，毕竟售后不能在你提问前先查询你的经验和能力。

典型的案例

For human，For fun 我们做到了！

这里我会举几个我们公司排查故障时遇到的典型案例，供大家理解上述内容的使用方法。

机器人定位丢失案例

有一次在客户现场调试机器人，发现机器人在导航的过程中定位会突然丢失，而且不是频繁发生，而是偶发性的（没有时间上的规律）。我们最一开始推断可能是和场景有关（从环境的角度寻找规律），但是定位跳变程度远超平常见到的定位丢失形式（推断被否定，但未验证），所以我们开始让车频繁的在场地中运动（极限测试），然后观察其在什么情况下会发生定位丢失的问题（试图寻找其它维度的规律）。具体的做法是当定位丢失发生时，使用手柄控制机器人倒着追寻原有的路径重新走过定位丢失的地点，然后观察机器人的现象（观察其它维度的变化）。经过几次测试，发现定位丢失现象也会在手动控制机器人时发生（初步发现规律），然后我们尝试了改变环境（等效替换，尝试排除正常的功能以构建最小复现系统），发现定位丢失依旧发生（基本确定和环境无关系），然后又发现故障复现的方式是在定位丢失的时刻，反复用手柄操控车经过丢失点（极限测试），但是这个丢失点位置并无规律，所以我们推测问题与车的运动有关，和环境无关，结合机器人的定位方式（知识体系），我们推测车的里程计出了问题（新推断）。这个时候我们将定位导航功能关闭，仅保留车的里程计计算部分（尝试构建最小复现系统），然后观察里程计的信息是否会发生跳变（验证规律的假设），经测试确实是里程计的信息发生了跳变（现象从定位丢失，缩小到了里程计跳变）。因为里程计是通过轮编码器获得的，所以我们推测编码器的数值有问题（再一次尝试缩小问题，提出假设），然后我们将编码器的数值进行了记录，观察其在定位丢失时的变化情况。经观察确定了编码器值有异常跳变的问题。这里编码器值跳变有可能是编码器本身的问题，也有可能是程序问题。我们观察到数值跳变的位置与变量类型的数值范围有关（数值跳变的规律），然后通过排查驱动器手册，发现我们在编写程序时编码器变量数值类型选小了，导致了编码器值溢出，进而发生跳变（单元测试的重要性）。

鼠标行为异常案例

这是一个非常让人哭笑不得的案例，但是可以体现故障排查中的某些小概率情况。我的同事在调试程序时发现他的电脑鼠标经常失灵，具体表现是只能做移动操作，但是左右键都无法工作。同事在一开始的时候以为是显卡驱动的问题，认为鼠标在工作，但是系统界面发生了卡死（第一次假设）。但是在对上述假设进行验证时发现，键盘可以正确的触发界面（等效替换验证界面是否卡死），可以切换程序也可以打字，所以可以证明界面并未发生卡死（假设不成立）。紧接着将问题聚焦到了鼠标控制这一功能上面，我们的推测可能是鼠标驱动有问题，或者鼠标本身有问题。因为很少见到鼠标软件驱动的问题，所以我们优先排查鼠标硬件问题（根据对系统的理解进行模块拆分，然后再根据经验对排查顺序进行优化）。鼠标硬件的问题可以分为按键本身、鼠标整体以及接口问题。我们决定先更换鼠标进行试验（等效替换进行验证），然后发现问题依旧存在，所以鼠标的问题被排除了。接下来是USB接口的问题，遵循最小复现系统的原则，开始拔出所有无关的USB设备。搞笑的事情出现了，同事发现计算机还连接了另外一只有线鼠标，且这只鼠标被压在了桌面的杂物堆下面（“怀疑一切”的重要性）。当我们拔出这个鼠标后，发现原有的鼠标恢复了正常，我们推测是这只有线鼠标被杂物压到了鼠标键，与同事正在使用的鼠标发生了按键冲突。

 

这次故障排除进一步说明了，很多问题的缘由并没有多么的复杂，很可能是一个非常诡异的，意想不到的错误导致的。如果一开始就从复杂路线进行修复，浪费时间不说，还解决不了问题。

总结

方法论的东西在没有经验的情况下看着很没意义，只有多试多总结才能真正得到提高。希望本文中的经验能为各位研究者提供些许帮助。最后祝大家在研究的路上披荆斩棘！无BUG！不加班！