本文約3873個字，預(yù)計閱讀時間10分鐘

故障排查的“方法論”

經(jīng)驗分享篇

機(jī)器人是一個綜合性比較高的產(chǎn)品，涉及多種學(xué)科的知識，如果沒有受過系統(tǒng)的機(jī)器人培訓(xùn)，面對故障時很可能一點頭緒都沒有。

我們在機(jī)器人行業(yè)有些年頭了，自己做機(jī)器人，集成機(jī)器人，現(xiàn)場調(diào)試機(jī)器人，同時還負(fù)責(zé)給客戶們做技術(shù)支持。這么多年過去了我們也算是有了些設(shè)備調(diào)試、排錯的經(jīng)驗，所以想寫下來給剛進(jìn)入機(jī)器人行業(yè)的研究者以及同學(xué)們參考，幫助大家少走些彎路。

不要著急歸因

故障發(fā)生時，很容易犯的一個錯誤是，不對現(xiàn)象進(jìn)行仔細(xì)的排查，憑經(jīng)驗直接下結(jié)論。確實憑經(jīng)驗有時可以快速的解決問題，但是一旦方向錯誤了，花費的時間可能比按照標(biāo)準(zhǔn)方法排查還要長。所以我的建議是要嚴(yán)格遵循故障排查的基本原則，憑借經(jīng)驗加速故障排查過程，而非省略某些過程。當(dāng)你確認(rèn)了現(xiàn)象與故障點之間的因果關(guān)系后，再進(jìn)行后續(xù)的步驟。

注意：緊盯系統(tǒng)給出的故障提示

很多人會因為錯誤碼太多，或者看不懂英文而忽視系統(tǒng)給出的錯誤，憑借自己的推測進(jìn)行排查。這是不可取的，系統(tǒng)錯誤信息往往包含故障的關(guān)鍵原因，有時候憑借故障碼手冊可以快速的定位到問題。所以不論系統(tǒng)拋出的故障信息多么繁雜，一定要仔細(xì)查閱。

尋找故障的規(guī)律

有些故障可能是間歇性的、時有時無的。找到故障的規(guī)律，對問題復(fù)現(xiàn)以及測試都是非常有利的。規(guī)律可能體現(xiàn)在時間維度上，比如在固定的時間點，或者固定的時間間隔；也有可能體現(xiàn)在其它維度上，比如機(jī)器人的關(guān)節(jié)在某個特定角度下，或者特定的運動模式下，或者在特定的環(huán)境中會出現(xiàn)故障。在尋找規(guī)律時要仔細(xì)思考故障發(fā)生的時與平時正常運行時的差別，任何細(xì)節(jié)都不放過。

構(gòu)建復(fù)現(xiàn)故障的最小系統(tǒng)

有效的故障排除法是在故障發(fā)生時，逐步關(guān)閉沒有問題的模塊，直至找到復(fù)現(xiàn)故障的最小系統(tǒng)形態(tài)。我在開頭也說過，機(jī)器人是一個復(fù)雜度很高的產(chǎn)品，由多個組件多個軟件模塊構(gòu)成。要明白的是，不同的模塊出問題時，機(jī)器人的現(xiàn)象有可能一致的，起碼在經(jīng)驗不豐富的時候是很難分辨出來到底是什么地方出了問題。所以我們要通過削減系統(tǒng)的方式，排除掉正常的功能模塊，將故障點凸顯出來，為后續(xù)的故障分析做準(zhǔn)備。

要有質(zhì)疑一切的心態(tài)

不怕系統(tǒng)發(fā)生大問題，就怕系統(tǒng)發(fā)生小問題。原因是大問題的特征極其明顯，故障排查非常好做，但是小問題的根源總是藏的非常深，很難找到。在故障發(fā)生后，要對所有技術(shù)點進(jìn)行質(zhì)疑和驗證，尤其是那些看似不容易出錯的地方。有人可能會說這樣做太浪費時間了，但是要明白，如果真的是這些不容易出錯的地方發(fā)生了錯誤而你沒察覺，調(diào)試的時間可能要漲好幾倍。所以充分的質(zhì)疑是有必要的。推薦的做法是，對最小復(fù)現(xiàn)系統(tǒng)中理應(yīng)正常的模塊進(jìn)行快速的驗證，然后再排查那些不太容易排查的模塊，這其實也是在幫助我們進(jìn)一步獲得復(fù)現(xiàn)故障的最小系統(tǒng)。

等效替換與極限測試

最常用的故障排查方式是等效替換與極限測試。等效替換指的是將你認(rèn)為可能出問題的地方進(jìn)行等效替換，然后觀察整個系統(tǒng)是否恢復(fù)了預(yù)期。替換包括實物的替換，軟件版本的替換，以及使用假的合理數(shù)據(jù)進(jìn)行模擬仿真。極限測試指的是在一些現(xiàn)象不是很明顯時，可以通過賦予系統(tǒng)參數(shù)極值的方法，放大某些現(xiàn)象從而尋找規(guī)律。不過使用時要注意極值帶來的系統(tǒng)的不穩(wěn)定，所以要做提前好保護(hù)措施，例如架空機(jī)器人，建立隔離區(qū)，以及準(zhǔn)備多種緊急停止的方案等，避免造成其它損壞。

系統(tǒng)性的知識體系

上面提到的故障排查方法其實都是方法論，決定方法論執(zhí)行好壞的是個人的知識體系是否健全。故障排查考察的是一個人對系統(tǒng)的認(rèn)知的完整度，你是否明白系統(tǒng)是如何構(gòu)成的，是否知道各部分之間的關(guān)聯(lián)形式，以及你是否知道系統(tǒng)結(jié)構(gòu)的優(yōu)勢劣勢，都會對你排查故障起決定性作用。我們公司在對客戶進(jìn)行售后培訓(xùn)時，經(jīng)常會和客戶強(qiáng)調(diào)不論研究重點是什么，都應(yīng)當(dāng)系統(tǒng)性的了解機(jī)器人相關(guān)知識，了解機(jī)器人的構(gòu)造、控制模型以及各種限制，這不僅僅是為了排查故障，更是為了讓客戶充分發(fā)揮機(jī)器人的優(yōu)勢服務(wù)于他們自己的研究。

尋求幫助的技巧

如果問題已經(jīng)超出了你能解決的能力，或者你需要在短時間內(nèi)完成排查，那么你可能會通過多種渠道尋求他人的幫助，比如在一些網(wǎng)站上發(fā)帖或者直接聯(lián)系設(shè)備商尋求幫助。需要注意的是這些渠道的溝通往往缺乏時效性。為了盡快的解決問題，溝通的技巧非常的重要。如果你經(jīng)常訪問Github或者StackOverflow之類的網(wǎng)站，你會發(fā)現(xiàn)他們提供了很好的提問模板，請盡量遵從它們，這非常有利于減少溝通次數(shù)。原因其實和上述描述的技巧有非常大的關(guān)系，如果你能準(zhǔn)確的描述故障的現(xiàn)象和規(guī)律、使用設(shè)備的環(huán)境與方法以及你做過的嘗試，其他人能夠快速跟進(jìn)到故障排查工作中，而非從頭開始做起。而且描述的越準(zhǔn)確，越有利于幫助者判斷你的技術(shù)能力，進(jìn)而使用你能聽懂的方式進(jìn)行溝通。如果你有過消費產(chǎn)品售后咨詢的經(jīng)驗，你會發(fā)現(xiàn)他們最一開始問的問題都非常的基礎(chǔ)，甚至?xí)屇阌X得他們把人當(dāng)傻瓜看，但是這是避免出現(xiàn)“聽不懂”以及“誤判”現(xiàn)象的最好的方法，畢竟售后不能在你提問前先查詢你的經(jīng)驗和能力。

典型的案例

For human，F(xiàn)or fun 我們做到了！

這里我會舉幾個我們公司排查故障時遇到的典型案例，供大家理解上述內(nèi)容的使用方法。

機(jī)器人定位丟失案例

有一次在客戶現(xiàn)場調(diào)試機(jī)器人，發(fā)現(xiàn)機(jī)器人在導(dǎo)航的過程中定位會突然丟失，而且不是頻繁發(fā)生，而是偶發(fā)性的（沒有時間上的規(guī)律）。我們最一開始推斷可能是和場景有關(guān)（從環(huán)境的角度尋找規(guī)律），但是定位跳變程度遠(yuǎn)超平常見到的定位丟失形式（推斷被否定，但未驗證），所以我們開始讓車頻繁的在場地中運動（極限測試），然后觀察其在什么情況下會發(fā)生定位丟失的問題（試圖尋找其它維度的規(guī)律）。具體的做法是當(dāng)定位丟失發(fā)生時，使用手柄控制機(jī)器人倒著追尋原有的路徑重新走過定位丟失的地點，然后觀察機(jī)器人的現(xiàn)象（觀察其它維度的變化）。經(jīng)過幾次測試，發(fā)現(xiàn)定位丟失現(xiàn)象也會在手動控制機(jī)器人時發(fā)生（初步發(fā)現(xiàn)規(guī)律），然后我們嘗試了改變環(huán)境（等效替換，嘗試排除正常的功能以構(gòu)建最小復(fù)現(xiàn)系統(tǒng)），發(fā)現(xiàn)定位丟失依舊發(fā)生（基本確定和環(huán)境無關(guān)系），然后又發(fā)現(xiàn)故障復(fù)現(xiàn)的方式是在定位丟失的時刻，反復(fù)用手柄操控車經(jīng)過丟失點（極限測試），但是這個丟失點位置并無規(guī)律，所以我們推測問題與車的運動有關(guān)，和環(huán)境無關(guān)，結(jié)合機(jī)器人的定位方式（知識體系），我們推測車的里程計出了問題（新推斷）。這個時候我們將定位導(dǎo)航功能關(guān)閉，僅保留車的里程計計算部分（嘗試構(gòu)建最小復(fù)現(xiàn)系統(tǒng)），然后觀察里程計的信息是否會發(fā)生跳變（驗證規(guī)律的假設(shè)），經(jīng)測試確實是里程計的信息發(fā)生了跳變（現(xiàn)象從定位丟失，縮小到了里程計跳變）。因為里程計是通過輪編碼器獲得的，所以我們推測編碼器的數(shù)值有問題（再一次嘗試縮小問題，提出假設(shè)），然后我們將編碼器的數(shù)值進(jìn)行了記錄，觀察其在定位丟失時的變化情況。經(jīng)觀察確定了編碼器值有異常跳變的問題。這里編碼器值跳變有可能是編碼器本身的問題，也有可能是程序問題。我們觀察到數(shù)值跳變的位置與變量類型的數(shù)值范圍有關(guān)（數(shù)值跳變的規(guī)律），然后通過排查驅(qū)動器手冊，發(fā)現(xiàn)我們在編寫程序時編碼器變量數(shù)值類型選小了，導(dǎo)致了編碼器值溢出，進(jìn)而發(fā)生跳變（單元測試的重要性）。

鼠標(biāo)行為異常案例

這是一個非常讓人哭笑不得的案例，但是可以體現(xiàn)故障排查中的某些小概率情況。我的同事在調(diào)試程序時發(fā)現(xiàn)他的電腦鼠標(biāo)經(jīng)常失靈，具體表現(xiàn)是只能做移動操作，但是左右鍵都無法工作。同事在一開始的時候以為是顯卡驅(qū)動的問題，認(rèn)為鼠標(biāo)在工作，但是系統(tǒng)界面發(fā)生了卡死（第一次假設(shè)）。但是在對上述假設(shè)進(jìn)行驗證時發(fā)現(xiàn)，鍵盤可以正確的觸發(fā)界面（等效替換驗證界面是否卡死），可以切換程序也可以打字，所以可以證明界面并未發(fā)生卡死（假設(shè)不成立）。緊接著將問題聚焦到了鼠標(biāo)控制這一功能上面，我們的推測可能是鼠標(biāo)驅(qū)動有問題，或者鼠標(biāo)本身有問題。因為很少見到鼠標(biāo)軟件驅(qū)動的問題，所以我們優(yōu)先排查鼠標(biāo)硬件問題（根據(jù)對系統(tǒng)的理解進(jìn)行模塊拆分，然后再根據(jù)經(jīng)驗對排查順序進(jìn)行優(yōu)化）。鼠標(biāo)硬件的問題可以分為按鍵本身、鼠標(biāo)整體以及接口問題。我們決定先更換鼠標(biāo)進(jìn)行試驗（等效替換進(jìn)行驗證），然后發(fā)現(xiàn)問題依舊存在，所以鼠標(biāo)的問題被排除了。接下來是USB接口的問題，遵循最小復(fù)現(xiàn)系統(tǒng)的原則，開始拔出所有無關(guān)的USB設(shè)備。搞笑的事情出現(xiàn)了，同事發(fā)現(xiàn)計算機(jī)還連接了另外一只有線鼠標(biāo)，且這只鼠標(biāo)被壓在了桌面的雜物堆下面（“懷疑一切”的重要性）。當(dāng)我們拔出這個鼠標(biāo)后，發(fā)現(xiàn)原有的鼠標(biāo)恢復(fù)了正常，我們推測是這只有線鼠標(biāo)被雜物壓到了鼠標(biāo)鍵，與同事正在使用的鼠標(biāo)發(fā)生了按鍵沖突。

這次故障排除進(jìn)一步說明了，很多問題的緣由并沒有多么的復(fù)雜，很可能是一個非常詭異的，意想不到的錯誤導(dǎo)致的。如果一開始就從復(fù)雜路線進(jìn)行修復(fù)，浪費時間不說，還解決不了問題。

總結(jié)

方法論的東西在沒有經(jīng)驗的情況下看著很沒意義，只有多試多總結(jié)才能真正得到提高。希望本文中的經(jīng)驗?zāi)転楦魑谎芯空咛峁┬┰S幫助。最后祝大家在研究的路上披荊斬棘！無BUG！不加班！