我們機器視覺項目的程序包含,業(yè)務(wù)邏輯+圖像處理,所以我們不單單調(diào)試圖像處理部分,還要調(diào)試C#,界面,數(shù)據(jù)等等。我們必須保證程序穩(wěn)定性,還要保證視覺檢測的穩(wěn)定性。
據(jù)說,有個機器視覺工程師因為現(xiàn)場客戶把光源拆了,讓他來現(xiàn)場重新調(diào)整光源位置,這位機器視覺工程師第二天就不來公司了,沒有走任何辭職流程,果斷收拾走人。
某天領(lǐng)導(dǎo)說,這個視覺檢測簡單,早點搞完。過了一段時間,你在調(diào)試,領(lǐng)導(dǎo)來一句,怎么還在調(diào)試。-摘錄大多數(shù)不懂裝懂,沒事裝逼類型領(lǐng)導(dǎo)語錄。
兄弟們,有沒有為自己拼過命,萬萬沒想到為了幾個像素波動拼過命,連續(xù)調(diào)試五個小時沒有穩(wěn)定下來,吃完夜宵,再看,像素波動穩(wěn)定了。第二天跑起來一點問題沒有。萬萬沒想到第三天,不穩(wěn)定了,原因是客戶把照明燈關(guān)掉了。
機器視覺工程師在機器調(diào)試過程中毀滅自我,拉扯自我,撕裂自我,重塑自我,否定自我,肯定自我,重啟自我
在我看來,這些是造成 bug 的原因,不是造成大部分時間在 debug 的主要原因。
大部分 debug 時間應(yīng)該是花在 bug 復(fù)現(xiàn) 和 bug 定位,所以你可能可以寫出不用 debug 的程序,但是不可能不需要測試,而且我覺得在寫程序自己測試的那段時間不叫 debug ,通常一邊寫代碼一邊測試那段時間所發(fā)現(xiàn)的 bug 都可以迅速找到的,并且可以及時處理解決掉,甚至解決不了,也要去避免這種類型的bug。
那么程序debug原因有哪些?
1.每種編程語言自身都有bug,當(dāng)你感覺對的時候,編程語言的體系根本不允許這樣子去實現(xiàn),你要在他規(guī)則下去寫程序,但是它的這個規(guī)則往往就是最大的bug,規(guī)則本身就紊亂,所以編程者理解它規(guī)則的同時,還要去按照這個規(guī)則走下去,那么走下去的流程,每個人都不一樣,因為每一個人理解的都不一樣。
2.邏輯性錯誤,從一些小代碼片段來說你可能沒有問題。那么,經(jīng)過一百個亂七八糟的跳轉(zhuǎn)之后,你還能看出錯誤來么?暈了,找啊找,找了半天,定位到bug,各種方法嘗試修改。
3.代碼健壯度,同上,你不可能考慮到所有狀況,因為很多狀況出現(xiàn)的問題都不嚴(yán)重,無非是重試或者警告,那么有些狀況在必須處理的前提下,你也是同樣容易被忽略的。并不是說沒有人愿意寫出超級健壯的代碼,而是,想那么多有什么用呢,萬一不出錯呢?
4.編寫效率,你是在debug 的時候發(fā)現(xiàn)錯誤的概率高,還是在自己腦子里發(fā)現(xiàn)錯誤的效率高。大部分人都是前者,如果你在腦子里就發(fā)現(xiàn)了錯誤,也就輪不到Debug時候發(fā)現(xiàn)了,所以一般人的做法是,寫完再說。
5.其實我并不知道這么寫是為什么,但是我覺得這么寫就是對的。這種,要么真對了,要么錯的一塌糊涂,但是你不能說這是蒙的,至于對不對,debug會告訴你真相。
6.我們腦子里并沒有計算機,所以你永遠不知道結(jié)果。
圖像處理debug的原因有哪些?
機器視覺需要反復(fù)調(diào)試的原因有以下幾點:
圖像集的質(zhì)量不同,需要針對不同的圖像集進行調(diào)試;
算法的參數(shù)設(shè)置不同,需要不斷調(diào)整參數(shù)以達到最優(yōu)效果;
硬件設(shè)備的差異,需要根據(jù)不同的硬件設(shè)備進行適配;
環(huán)境的變化,比如光照、角度等因素會影響機器視覺的效果,需要進行相應(yīng)的調(diào)整。
因此,機器視覺需要反復(fù)調(diào)試才能達到最佳效果。
-
測試
+關(guān)注
關(guān)注
8文章
5031瀏覽量
126219 -
機器視覺
+關(guān)注
關(guān)注
161文章
4301瀏覽量
119864 -
編程語言
+關(guān)注
關(guān)注
10文章
1919瀏覽量
34502
發(fā)布評論請先 登錄
相關(guān)推薦
評論