公司有個視覺項目，本來相機拍照邏輯是飛拍加軟件觸發拍照，但是，經過前期驗證后，我給改成了靜止拍加硬觸發，因為被檢物體的移動速度實在是太快了，通過軟件觸發拍照很容易拍不到或者漏拍，我都做好了，可是，我們公司一個新入職的小伙子卻覺得我的方案不行，還是決定用飛拍加軟件觸發拍照，我只能說，還是太年輕了。

這個視覺項目的檢測內容很簡單，就是檢測液體是否正確滴下。首先，這個液滴很小，小到肉眼很難看到，其次，滴下的頻率很高，每秒大約要滴下上萬滴，但是，每一滴液體之間需要有特定的間距才算合格。

我最開始采取的方案跟小伙子是一樣的，也是選擇移動拍照和軟件觸發，但是發現有個問題沒法解決。

問題就是拍照時機的問題，因為液體滴下的頻率實在是太快，但是我們采購的相機幀率只有60幀，且畫面高度因為各種原因，只能看到兩個并列的液滴，所以，如果要檢測液滴之間的間距，那就必須保證畫面上有兩個同列存在的液滴才行。

可是，相機幀率只有60幀，理論上，相機在拍照時，每隔大約16毫秒才能拍到一張照片，而液滴的滴下速度大約是每秒1萬滴，因為頻率不同，會導致拍照的時機不同，很容易出現畫面上一滴液滴都沒有或者只有一滴液滴的情況。

之所以前期排除了飛拍和軟件觸發拍照的原因也是因為上述原因。

排除飛拍的原因是因為液滴太小了，稍微移動一下空間就會產生慣性風，影響液滴滴下軌跡，雖然可以通過下壓氣壓穩定液滴，但是這種情況只有在靜止情況下有效，因此，最后我們還是決定固定拍照。

而決定不使用軟件觸發的原因是因為使用軟件觸發，首先我們得先向相機發送一個拍照的命令，然后相機收到命令以后再觸發拍照，而軟件發送拍照命令和相機觸發拍照中間也會有一個時間差，這個時間差大約是1-5毫秒左右，而且，因為是循環取圖，還必須設置循環間隔，否則視覺系統很有可能會進入假死狀態，雖然時間很短，但也會影響其他功能。

這樣的話，還是會回到那個問題，那就是相機的拍照時機和液滴的滴下時機不一致，從而很容易出現拍不到液滴或只能拍到一個液滴。

因此，經過討論，我們還是決定使用電信號觸發，因為液滴的滴下也是通過板卡信號觸發滴下的，因此，我們直接將相機的拍照信號線接在了板卡上，這樣，當液滴滴下信號被觸發時，相機的拍照信號也會被觸發，這就使得液滴的滴下和相機的拍照信號同步了！

實驗過后，我們發現相比使用軟件觸發，使用板卡信號觸發也就是使用電信號觸發相機拍照，拍攝到合格圖片的成功率是使用軟件觸發沒法比的。

因為我們前期在驗證時，使用軟件觸發拍照，最夸張的一次是拍了60張圖片，連一張可以用的都沒有，而使用電信號觸發，拍了60張圖片，只有一張不能用。

對此，新來的那個做視覺的小伙子給出了自己的方案，他覺得使用電信號觸發拍照完全沒有必要，而是走了另外一個路子。

他覺得既然既然是使用板卡信號來觸發拍照，那么完全可以使用軟件去監控板卡信號，然后當軟件監控到板卡信號以后，再使用軟件去觸發相機拍照即可，而他覺得靜止拍浪費時間，在沒有問任何人的情況下，單純憑個人感覺，還是改成了飛拍。

因為我的功能已經做好了，但老板對時間的確有點意見，一聽小伙子可以使用飛拍來節省檢測時間，二話不說就讓小伙子去做了。

我只好不說話啦！

但我知道，小伙子的這套方案有個很大的毛病，這個和飛拍沒有關系，光使用軟件去監聽板卡觸發信號就有一個問題是他沒考慮到的。

他的意圖和我一樣，都是想要在板卡觸發液滴滴下的時候去拍照。

但是，監聽板卡觸發信號，他估計只能做一個循環去監聽板卡某個IO點的信號，或者是使用特定的通訊協議去獲取板卡當時的狀態。

但不管怎么樣，這個循環，也是一定要設置一定的間隔的，即使是拋開間隔不談，他和板卡通訊也是需要時間的，這個時間和直接使用電信號觸發產生的時間是沒法比的。

假設板卡觸發液滴滴下的時間間隔是100微秒，那么可能軟件在收到這個滴下信號的時候已經是500微秒以后了，光滴都已經滴了5次了，也就是說，這個滴下信號的監控本身就沒有什么意義。

其次，相機拍照是需要命令的，從給相機發送拍照命令到收到相機拍到的照片進行處理，這里也是需要時間的。

因此，也是很難繞開液滴滴下時機和拍照時機這個問題。

結語

我不敢說這個小伙子的方案一定不行，但是，我覺得解決問題的概率不大，何況他還決定要飛拍！

但是，從我的角度來說，在不改硬件的情況下，目前來說，如果小伙子對我上述所說的問題都知曉的話，那么他的方案其實就是純碰運氣的心理，想著液滴滴下頻率已經那么高了，一定能拍到，但是這種心態在做項目時一點也不可取！

如果他對我上述所述的問題一點都沒有考慮到的話，那就是太年輕了！我想說的是，我雖然做機器視覺的時間不長，但總歸比他這個新兵蛋子考慮問題要周全吧？

最后，新來的小伙子經過驗證，發現通過軟件觸發拍照和飛拍的確有很大問題，加上項目比較緊，已經來不及研究了，所以，又改回了我采取的方案，何必呢？浪費時間罷了！