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

故障排查的“方法論”

經驗分享篇

機器人是一個綜合性比較高的產品，涉及多種學科的知識，如果沒有受過系統的機器人培訓，面對故障時很可能一點頭緒都沒有。

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

不要著急歸因

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

注意：緊盯系統給出的故障提示

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

尋找故障的規律

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

構建復現故障的最小系統

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

要有質疑一切的心態

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

等效替換與極限測試

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

系統性的知識體系

上面提到的故障排查方法其實都是方法論，決定方法論執行好壞的是個人的知識體系是否健全。故障排查考察的是一個人對系統的認知的完整度，你是否明白系統是如何構成的，是否知道各部分之間的關聯形式，以及你是否知道系統結構的優勢劣勢，都會對你排查故障起決定性作用。我們公司在對客戶進行售后培訓時，經常會和客戶強調不論研究重點是什么，都應當系統性的了解機器人相關知識，了解機器人的構造、控制模型以及各種限制，這不僅僅是為了排查故障，更是為了讓客戶充分發揮機器人的優勢服務于他們自己的研究。

尋求幫助的技巧

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

典型的案例

For human，For fun 我們做到了！

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

機器人定位丟失案例

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

鼠標行為異常案例

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

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

總結

方法論的東西在沒有經驗的情況下看著很沒意義，只有多試多總結才能真正得到提高。希望本文中的經驗能為各位研究者提供些許幫助。最后祝大家在研究的路上披荊斬棘！無BUG！不加班！