本人小恐龍，汽車圈IT從業近10年，於3年前不小心掉進物流機器人的大坑。作為汽車行業先進物流技術的探索者之一，希望將我這幾年在智能機器人的使用經驗和教訓和大家分享，希望可以為行業總結經驗，少走些彎路。那麽第一篇文章先來聊聊物流場景。
物流智能機器人已經在電商領域和快遞行業取得了非常大的成功，甚至有某"知名"電商宣稱可以提高分揀效率8-10倍。那麽這種成功是否可以在工業領域成功復制呢？以我在汽車行業的套用經驗來看，想達到人工效率，已經是成功了；超過人工，難度極高。
那麽這種新技術是否就在這個行業沒有價值呢？相反，有很大價值。透過合理的設計，效率上可以達到人工的2倍左右（但不足以產生明顯的正向ROI）；同時，可以大大減少勞動強度；減少藍領的腦力消耗；有效提高操作準確性；有效降低培訓時間；最重要的是，可以有效降低招聘門檻，可以解決在不提高薪資水平的條件下，招不到人的困境(實際上是可以降低標準招人)。透過這種技術，可以在不提高用工成本的前提下，保證高準確率操作的要求，而對操作準確性的要求，是工業領域絲毫不能妥協的關鍵 （不準確不規範的操作，給客戶造成的損失，要遠遠大於電商類別業務）。
下面我們來按照物流和使用關鍵要素來詳細討論汽車配件庫房的套用場景。本文並不會太涉及這種機器人的內部設計. IT整體方案的設計,將會在以後的文章中單獨討論, 也不會在本文中體現.
1）罪魁禍首：汽車配件SKU太復雜
在汽車售後零配件庫房，SKU的貨物品類，基本在幾萬到十萬種上下，這種SKU品類的密度，是普通電商庫房的幾倍甚至幾十倍（電商庫房會按照SKU品類分庫，即不同性質的貨物不會放在一個庫房裏，所以雖然商城裏SKU多大幾十萬種，但是每個庫房卻相對單一）。
在這數萬種SKU裏，按照包裝體積，分成大(發動機，保險杠)，中（雨刷），小（火花塞），微（螺絲，墊片）多種；按照重量，有的體積大但是很輕，有的很小但是密度極大（剎車片）；按照流動速度，又分成A類（每天有流動），B類（每月有流動），C類（每月有流動），D類（每年有流動。。。就是傳說中的，遭人恨的長尾貨）；按照銷售最小包裝，有的需要一個螺絲一個螺絲的數，耗時極大。
可見，如此多維度的SKU分類，造成了一個棘手的問題是，針對中小件儲存區域，庫房每平方米要儲存的SKU品類將會高達十甚至數十種。而為了最有效利用儲存空間和貨物管理，電商庫房常用的一貨多位儲存方式，在汽車零配件庫房是很難采用的(補貨貨位是有的, 但是不做進出庫).
不幸的是，中小件，正是物流機器人最適用的SKU場景，所以在整個方案的設計裏，必須要兼顧儲存空間利用率，操作準確性，管理準確性，效率，機器人數量成本等相互矛盾的訴求。怎樣在這些矛盾中尋求突破，用好機器人器材，這是本文要討論的內容.
2）一貨多位，還是一貨一位？
由於SKU品類太多，造成庫房很難做到一貨多位的管理。一貨一位，是庫房進行人工貨位調整，人工貨位最佳化的基礎，如果使用一貨多位，人工管理的難度將會大大升高，管理的有效性有大大降低的風險，管理成本會大大提高。對貨位的最佳化，將會達不到期望的效果。那麽專業的IT系統是否可以付能管理人員進行一貨多位的管理呢？仍然非常困難，因為除了管理成本，一貨多位會對一線操作人員造成困惑，會影響一線的操作效率。自動化器材的引入，可以幫助一線操作人員解決這個問題。一貨多位是這種物流機器人的核心優勢之一。
另外，一貨多位會造成的一個問題是容積，有可能會使貨位的容積浪費變大，另一個問題是SKU的存放位置的設定就變得異常復雜。有人會問為什麽不做用大數據做貨位的基於演算法的冷熱分析來解決這個問題呢？由於汽車零配件的來源極其復雜，造成上下遊的主數據，包裝單位數據很難統一規範。不準確的各種基礎數據，是本行業的特點和一直以來的痛點，盡人皆知，影響很大，無人能解。
大數據和運籌學在倉儲領域擅長的SKU冷熱分析，由於數據的缺失，也難有發揮的空間，間接的，造成了物流機器人系統不可能透過機器人自主的調整貨架位位置來最佳化效率。
我們在使用機器人的過程中，可以考慮用漸進式的方式，先一貨一位，逐漸補齊數據，慢慢過渡到一貨多位。一步到位，是不可取的方式。
需要註意的是，如果機器人方案裏不具備實施一貨多位的條件，那麽同一種貨物將會只在一個貨架上出現，在揀貨任務分配邏輯上，需要重點考慮不同工作站（件貨台）之間的貨架調撥邏輯。
3）阿彌陀佛，貨架頂歪了！
首先，再一次，還是由於單位面積的SKU品類太多，機器人貨架必須要設計成能夠承載最多品種的貨物，最多時單個貨架需要設計多達50種SKU，那麽必然要求貨架需要有足夠大的人工操作界面，說白了，就是需要設計的足夠高，能容得下很多層。同時又必須兼顧人員操作的便利性，那麽貨架的儲存凈高度應該在1.8米左右（總高度2米左右）。這樣的設計問題是，會使得貨物的中心偏高，造成貨架傾倒的機率變大。貨架的具體設計，在下一章做詳細討論。
其次，由於SKU最小包裝單位的缺失，和貨物重量數據的不準確，在機器人上貨和揀貨的時候，系統不能自動計算貨架兩側的重量平衡，和上下層貨位的中心分布。一旦貨架重心分布和總重量超過了一定閾值，貨架在加速，減速，旋轉過程中都有可能發生傾倒。（數據的缺失，是由於整個行業的數據缺失和供應鏈上下各個環節沒有打通所致，這並非一家公司可以解決的問題，需要整個供應鏈的共同努力。這個話題太大，可以另作討論，大家知道結果就行，就是沒數據，即便有，也不準確。有人說用區塊鏈？按照行業規律，誰說區塊鏈誰就是來騙錢的！）。
重心的偏移，還會導致機器人本身受到的壓力不平均，時間久了，會造成承重部件的過度磨損，比如某個方向的萬向輪，托盤旋轉電機，減速機，齒輪箱等。一旦出現機器人關鍵部件磨損，會造成貨架轉向不足/過度。而一旦機器人沒有檢測到偏移，就會出現因為一個歪的貨架行進在路上，剮蹭到一排貨架的情況。
為了避免/減小貨架歪了的情況出現，需要在上架的時候，將重的貨物放在盡量靠下的位置。同時需要註意貨架的左右面的重量分布不能過偏。對重量分配的調整，需要現場操作人員持續的關註，會給一線員工造成額外的管理開銷。
4）貨位設計，這是門玄學
在汽車售後配件行業，對貨位的管理，絕對稱得上是一門玄學。
一個汽車售後配件庫房，面積一般在1萬-5萬平米之間；常備的SKU在3萬-5萬種之間。安全庫存，我們拿業界最高的履約標準來看的話，庫存周轉周期在3個月左右，庫存價值在1-10億RMB之間。
那麽如何才能對如此復雜的SKU進行有效的儲存管理？既要考慮對三維空間的利用效率，又要考慮庫房總體吞吐能力的最優，同時還要考慮為在途的貨物預留（大量的貨物需要進口。空運海運清關的時間周期和單個批次貨物總量都不相同）；既要考慮貨來了，能及時完成上架（否則會占用開放區，堵死操作），又要考慮揀貨時候容易撿出（成托盤上貨，拆零揀貨，所以上貨揀貨對貨位的要求明顯不同），還要考慮危化品，磁性，精品，高價值貨物的不同特性。。。而貨物的大小，重量，包裝規格，運輸單位，數量，易碎品等，只不過是研究貨位的基本功課而已。
那麽怎麽樣才能有效地管理如此多的因素呢？目前，在汽車行業，演算法還不能和經驗相提並論，大數據不如Excel，是常態。AI能幫忙嗎？過擬合，欠擬合的發生都會是個大悲劇，因為庫房操作的容錯性很低，操作必須可知可控可預測。運籌學在不考慮成本的前提下，是個正確的方向，越大的庫房越需要演算法支持。但是規模很大的倉居里面也同時有大專家蹲守，而不具備專家的小庫房，有沒有必要用演算法。。。靠人肉足以。業界宣稱的技術是一回事，實際使用的效果是另一回事，在這裏有充分體現。
貨架是由許多貨位組成的，而不同的SKU對貨位要求千差萬別，我們需要首先研究研究貨位。從倉儲的管理角度看，貨位是貨物的基本管理單元，涉及到庫房一共能儲存多少種品類的貨物，總重量，總體積，儲存類別，位置等關鍵資訊；而從單個SKU角度看，貨位又是某個品類貨物的儲存內容, 在倉儲管理系統中，物料主數據裏，一定會有一個以上關鍵欄位是貨位，用來傳遞這個貨物儲存位置的資訊。一個貨位，繫結了物料在這個庫房種的三維位置資訊，流動特性，物料重量特征，體積特稱，包裝特征等很多資訊。
談清楚了貨位設計的基本因素之後，我們可以談談機器人貨架的設計了。
首先，在設計機器人貨架的時候， 要搞清楚我們的目標物料是哪些，從最小的到最大的，從最輕的到最重的，再找到最獨特的包裝的。根據我們的經驗，有三類貨物需要重點關註。第一種是揀選很花時間的，比如螺絲，如果會單個揀選的話；第二種是密度很大的，比如剎車片，這種物料的包裝規則，容易存取，體積小密度大，所以很容易造成貨架整體重心偏移，導致貨架側傾；第三種是重量輕但是包裝易滑的，比如塑膠膜包裝，這種配件在貨架移動時候，很容易滑動，需要對貨架容器開口做特殊處理。針對不同的配件包裝，需要設計寬度，深度，高度非常不同的貨位容器。
其次，我們需要考慮機器人貨架要儲存多少體積的物料，在配件清單定義清楚的情況下，進一步需要考慮的是每一種配件的流動速度，即吞吐量。這裏吞和吐兩個流向需要分別考慮，因為庫房一定是大口吃進去，小口吐出來，那麽每種貨位的總容積，需要滿足這個配件的庫存周轉周期，外加安全庫存的冗余。
第三，需要考慮不同配件之間有可能的耦合關系。比如保養件，如果是需要成套銷售的，那麽這些配件是高度相關的，那麽將這些配件放在相同的貨架上，一次全部撿出同一個貨架上的貨物的機率就會增大，進而提高吞吐效率。具體怎麽分配物料和貨架的耦合關系，需要有足夠的數據作為支撐，一貨一位還是一貨多位，就是是設計的關鍵。
綜合上面三個要素，貨架的貨位組合關系，怎麽最佳化，就需要一個長期的最佳化過程。根據我們的經驗，貨架的分類不宜過多，貨位應該以大型和中型為主。中型的貨位應該放在貨架的中間高度，以便人員容易操作。貨架應該分成AB兩面，每一面的深度應該相同，這樣可以有效利用工作面，多放貨位，同時可以保證中心容易平衡。貨位工作面，不應該小於一個拳頭的大小，以便手的進出。
貨架的邏輯設計完成之後，還需要考慮貨架的材料。
首先，貨架的立柱，橫撐，隔板，應該盡量使用高強度輕質材料。根據我們的經驗，一個兩米高的貨架，如果是普通鋼材制作，自身的凈重就會有70公斤左右，考慮到機器人的托舉能力最大500公斤的話，那麽光貨架就會損耗掉1/5，那麽機器人貨架的有效儲存重量只有350多公斤。且鋼制的貨架，容易生銹，時間一長（以年為單位），有貨架垮塌的風險。
其次，需要考慮貨架的容器，目前大部份現成的塑膠容器尺寸都不適合機器人貨架測尺寸，那麽我們需要考慮是以物料容器的尺寸來設計貨架的寬度，還是以貨架來客製物料容器。這個需要根據使用方和配套方的能力來綜合考慮。
需要註意的是，千萬不要用紙盒子作為容器！因為紙盒子受潮之後會膨脹變形，我現在還在流淚啊。。。。
5) 東邪西毒：合單一波流 VS 拆單流水線
前面的四個章節，我們分享了物流機器人在汽車配件庫房的套用的靜態要素。下面我們來討論動態要素。
訂單履約，是一個庫房存在的核心使命。履約，用大白話來說，就是要使客戶，及時的收到正確的貨，並保障沒有儲存和運輸的損傷。要保證履約，物流環節需要及時將貨送到客戶手上的話，除了運輸環節的情況外，最關鍵的就是庫房可以及時的將客戶要求的貨交割給承運商。那麽對於庫房來說，需要科學的去處理訂單，才能保證時間節點。怎麽處理訂單才是算是科學的？在保證履約並不難，但是要做到最合理的使用手頭的資源，最小化整個鏈條的成本，才能稱得上是科學的。在這個前提下，不管是合單處理，還是拆單處理，都是庫房根據各種限制條件和現有資源的合理選擇。
說到物流機器人方案，是不是合單處理-拆單處理這兩種模式都可以適應？小恐龍認為拆單流水線模式更適合機器人。機器人系統的設計方案必須要滿足庫房整體的履約能力的上限，才能在業務量大爆發時候不拖慢整個庫房的效率。基於這樣的考慮，機器人方案的設計難度，使用難度，容錯空間，都將會面對極大挑戰。為了滿足這些極端情況，機器人的數量必須要足夠，系統的控制邏輯要足夠嚴謹，容災和恢復能力要非常強，最終，為了滿足峰值時候的吞吐量，會造成整個方案的成本飆升，最終超出合理範圍（比人還貴）。考慮到機器人本身，最適合穩定的節拍，穩定的負載，所以說是適合生產線類別的操作節奏。那麽針對庫房，將收到的訂單整合成多批次，小負載的，穩定的流水線模式，是最能發揮機器人系統的優勢的選擇，機器人的單體壽命可以最大化，系統容錯空間大，成本低。
以小恐龍這幾年的使用經驗來看，機器人和流水線模式組合能相得益彰發揮優勢，但是機器人和訂單一波流模式的組合，有著難以克服的問題。必須要肯定的是，訂單一波流，是非常科學操作模式。在這種模式下，庫房會根據履約時間，向前推算訂單的最後截至時間，在盡量多的收集到訂單之後，免洗的處理訂單。這種操作方法，可以將不同客戶的相同訂貨整合，用最小的資源消耗去一次性命中最多的貨物；可以使庫房的操作按照時間段分片，可以用相同的空間和人力，在不同的時間段完成不同的作業，是綜合成本最小化的庫房管理方法。這是ToB類別的供應鏈庫房的首選模式。但是這種操作模式，會造成在某個峰值時段，操作負載極高，人工傳統模式的話，可以多撲人員來解決，但是對機器人方案來說，就要從一開始就要針對最大的吞吐量容量做設計。設計難度大，營運容錯率低，對機器人產品的質素穩定性要求極高，專案成本高，收益低（可以想象，要積攢一天的訂單在1-2小時裏面集中處理掉，所以極限負載極高，但是在這個時間端之外，有沒有多少任務可以作，所以機器人在大部份時間段在休息，浪費了投資）。
對機器人器材本身來說，高負載連續使用，會降低機器人壽命，這一點如果在操作種不能避免，就需要在商務協定中有所體現。
另外需要說明的是，機器人方案一定要基於庫房整體的操作規則做設計，要將器材融合進現有流程。不能融合進大流程的器材，並不具有實施的價值。另外一邊，大流程也需要針對機器人使用做細微變更，調整的好的話，可以取得雙贏局面。
6）大巧若拙：單次分揀還是多次分揀
上一段討論到了兩種揀貨模式的優缺點，那麽針對機器人方案並不擅長的合單一波流，有什麽辦法來最佳化揀貨效率呢？最關鍵環節的就是分揀層級的設計。
設計分揀層級，即每一級揀貨的顆粒度。一般來講，單次分揀粒度越高，本次揀貨效率越低（因為需要將撿的貨和客戶對應起來），但是同時需要的分揀次數就越少。針對不同的庫房，不同的貨物，不同的貨量，不同的客戶量，設計多少層分揀，需要根據具體情況而定，並沒有統一標準。
以一般的規律來看，區域的中心倉，超大型庫房，會設定多級分揀（單純揀貨-】在一個區域分客戶-】合單-】包裝），多級分揀能有效提高效率，但是需要很大的操作界面和人力和自動化器材。中小型庫房，會將中間某些環節合並操作。
那麽在本文討論的情景中，想使揀貨效率最大化，必須使每個貨架只需要移動一次就能命中本貨加上全部的貨物。基於這樣的思路，單次分揀是一定不能最大化吞吐量的，因為單次分揀，在揀貨的時候，需要同時將不同的客戶貨物區分開，而如果客戶數量很大，就需要很大的播種墻（播種墻的設計在後面討論），太大的播種墻會增加人員行走的時間，就是降低揀貨的效率。同時面積過大的播種墻，會占用很多庫房面積，也是成本。如果在揀貨時候不區分客戶呢？那麽單純揀貨效率會很高，但是後面還需要二次分揀來區分客戶。
這裏的平衡點，其實就隱藏在貨量和客戶量之中。當客戶數量大，但是每個客戶需要的貨量和品類很少的情境下，應該優先考慮二次分揀，因為一個貨架移動一次如果只命中一個訂單，貨架需要不停的被移動，機器人系統的效率將會很低，還會造成整個系統的負載很高；當客戶數量不大，但是每個客戶的訂貨很多情境下，如果二次揀貨，會有大量的貨需要再次被移動和分撥，而且會需要占用很大的面積去分客戶，所以不如在機器人貨架區域，一次性區分好客戶。
7）萬劍歸宗：路徑規劃
機器人要想完成一個指令，需要知道兩個關鍵資訊，第一，去哪，第二，怎麽走。處理這兩個資訊的任務就是路徑規劃，將這兩個任務變成機器人可以執行的資訊，就是路徑規劃演算法。路徑規劃演算法其實要解決的問題很簡單，從A點到B點。解決這個問題的方法和演算法，在所有的電腦專業本科課程裏都有闡述。但是，實際解決起來難度極大。
市面上的路徑規劃演算法分成兩大派系：集中式控制和分布式控制。
集中式控制，就是由一個核心節點掌控全域。將所有的即時資訊，包括機器人的位置，速度，加速度，角度，方向，舉升，全部匯總起來計算，並將計算結果即時的下發到機器人上去執行，機器人即時反饋資訊給中央控制節點。這種設計的優勢很明顯：簡單。機器人不需要承擔任何復雜計算（機構和傳統AGV類似），所有的計算邏輯由中心控制節點完成，在程式設計時，開發者可以明確分工，知識領域邊界清晰，開發效率高，邏輯簡單；其次是準確。伺服器端，擁有在任何時刻的全部地圖資訊，知道任何一台機器人的狀態和位置，可以做出最準確的判斷，並在同一時間將所有機器人的路線一次性計算出來，並下發，這種特性，在節拍要求高的生產線尤其重要。集中式控制在機器人數量，或者說計算量要求不高的情況下，是很好的架構。但是，當機器人數量上升，或者地圖變大時，會使得計算量指數性的提高，伺服器的負載會極大增加。那麽意味著需要提高伺服器效能，增加成本到不可接受的程度。（有同學會問，伺服器可以作集群，分布式平行計算，這個的確是個正確的方向，只不過需要將一個單一計算過程分變成分布式的計算，之後合並成一個結果，設計難度不低）。以目前行業的使用經驗來看，這種架構可以承載的機器人數量在300-400台左右。不過隨著運籌學的引入，演算法也在快速最佳化中，計算速度已經開始有了突破。國內所有主流機器人公司都是采用了集中式控制。
需要強調的是，路徑規劃問題是一個逼近最優解的問題，而非傳統編程上求對錯的問題。需要很強的數學方法論基礎。並非IT攻城獅擅長的領域。而所謂的最優解，有比較難的去定義，甚至需要根據具體實施來逐步摸索，是個很耗時間的工作（小恐龍在這裏為「杉數科技」做做廣告）。
和集中式控制相對的是分布式控制，即機器人本身承擔主要的計算並做出決策，每個機器人分布式計算，只關心自己附近的局部情況。在這種架構中，每一台機器人只會關心他自身附近的地圖資訊，保證不出現安全問題即可，路線可以一邊走一邊計算，計算的過程，也不需要考慮其他機器人的路線規劃。分布式控制仍然需要一個中心節點來為所有機器人同步地圖資訊，但不需要做路徑規劃計算。這種模式的優點就是計算量不會隨著地圖的復雜度和機器人數量快速增加（增加的只有通訊量，只是地圖座標，數據量不大）。這個優點可以使地圖近乎可以無限增大，在應對超大規模套用時候有優勢。分布式控制的缺點也很明顯，由於機器人只關心自身附近的情況，有可能會造成相當嚴重的堵車，一旦一個點位出現了堵車，由於並沒有一個中心統籌控制能力，其他的機器人仍然會向著堵車的位置行進，這樣會將單點的堵車規模迅速廣播擴大，造成連鎖反應。由於機器人本身只計算自身路徑，那麽在堵車區域裏面的機器人將很難沖出堵車區域。這點和現實生活中的堵車一摸一樣（倒是很好的現實模擬器）。要想解決堵車問題，需要對機器人分布式的演算法和態勢感知進行幹預，在堅持分布式控制的前提下，對演算法提出了很大挑戰。據說，亞馬遜的機器人就是用的分布式演算法。
底哪種控制方式更好呢？簡單來說，集中式演算法門檻低，但是潛力有限；分布式演算法潛力大，但是難度高。選取哪個方向，需要根據具體情況而定。在中國，庫房面積都不太大（跟美國相比），由於防火分區的限制，每一張地圖最大面積一般在5000平米，可容納的機器人在幾百台水平，那麽這種限制條件就決定了，在國內，使用簡單可靠的集中式演算法就足以滿足需求了。能邁過分布式門檻的公司，不會太多（不是說做不出來，而是能否達到商業使用的穩定程度和效率要求）。
要讓人民少跑路，數據多跑腿。不論什麽演算法，都要做到讓機器人物理上盡量少跑路。就近分配任務給機器人是個基本功，容易做到。單獨看每台機器人的話，基本原則是最短時間演算法，而不是最短路徑演算法。機器人移動時最花時間的地方在於轉向，而不是走直線，所以要盡量多走直線，少轉向。為了達到這個目的，就需要演算法在計算最短路徑的時候，考慮轉向的權重。在一個以方格為基本單位的地圖裏，最考驗演算法的就是在對角線上兩點的走法（用這個簡單操作，就可以檢驗出來機器人公司的演算法功力）。
走對角線的話，機器人走斜線不就行了麽？還真走不了。大家知道機器人是靠二維碼導航的（前文介紹過），靠雙電機來行走和轉向。在機器人行走過程中，機器人由於左右兩輪的轉速差異，地面起伏，負載中心位置等因素而會走偏，那麽糾偏，除了陀螺儀外，就是靠地面二維碼校正姿態（地面二維碼除了導航外，還還負責糾偏）。機器人會根據二維碼將自身的電機計數器，網絡攝影機，陀螺儀糾偏。在機器人制造的時候，需要用精密工裝來確保每個元件之間的位置精確性。如果讓機器人斜著走，即和二維碼的工裝方向產生一定角度，那麽必然會產生更大誤差（多出了一個偏移量角度），機器人即便能走到下一個碼上，也需要調正方向來校準，這樣的時間消耗反而會更大。除了效率考慮，還有安全性問題，如果機器人被允許斜著走，在演算法上還進一步需要考慮附近位置是否有足夠的空間，不會影響到其他車的移動，而直線行駛，只要碼間距設計合理，在演算法上就更簡單，安全性風險就更小。
8）九陰真經：地圖設計
地圖的設計一定要和機器人路徑規劃演算法來一起討論。離開了具體的路徑規劃演算法，地圖設計將會謬之千裏。所以地圖的合理性，和路徑規劃高度相關。
除了核心的路徑演算法之外，想設計一個好用的地圖，還需要考慮諸如物理環境，立柱，工作站大小，位置，單行道，機器人總量，排隊演算法，壁障演算法，充電規則，充電樁數量和位置因素而貨架的擺放位置和數量，效率，是綜合了全部因素之後的最終結果。
物理環境，首先需要考慮室內建築環境。各家機器人供應商對地面平整度都有自己的要求，這些建築專業術語轉變成一般人能理解的語言就是不能剮蹭機器人底盤，由於機器人的動力輪是中間位置左右各一個，一旦摩擦力變化，會造成左右動力輪受力不均，造成機器人跑偏。而由於地面不平刮蹭了底盤，使某一邊的動力輪懸空，是原因所在（這種情況下空車比有負載的車更容易發生跑偏）。一個簡單的測量方法是用3米靠尺，下凹最深處，3~4毫米就是極限了。至於大範圍的起起伏伏，並不會影響機器人安全執行。
物理環境，其次要考慮室外大環境的溫度和濕度。溫度很容易理解，目前這種機器人都是使用三元鋰電池來供電，這種電池的適用溫度是0~50攝氏度，在中國大部份庫房，並沒有高於40攝氏度的環境，而機器人也並沒有超大功率輸出的工況，所以高溫工作環境不是個問題；但是大量的北方庫房，比如北京的庫房冬天室內溫度就會低於0度，這個溫度，會使三元鋰結晶，會大大降低電池電量，更充不上電，如果硬要充電，會產生安全性風險，且大大降低電池壽命。目前很多電池包廠商可以提供內建加熱功能的Pack來解決低溫環境問題。低溫環境除了對電池有很大影響，也會對機械部件產生影響，比如各種減速機的齒輪會受到低溫影響，微小機械效能的改變在精密場景裏會被放大。
目前已經有機器人廠商釋出了冷鏈倉儲機器人，效果拭目以待。
除了溫度，濕度是個容易被忽視的問題。機器人的電子器件在高濕度的環境下容易損壞，是個眾所周知的問題，除了電子元件之外，地面二維碼的貼設也會不牢固。當地面有令凝水的化，有可能造成機器人打滑。
立柱，是第二個關鍵問題。當機器人執行環境裏有立柱的話，要註意立柱的住腳是否會影響機器人路線，這個問題並沒有技術難度，但是由於對圖紙的理解，不同環節有不同的認識，住腳問題有可能會被忽略。比較理想的解決方案是在施工過程中，將住腳埋在地面一下，地面不露出螺絲。
工作站的大小，是根據業務容量作為輸入來設計的，由於工作站是整個方案的物料的出入口，那麽需要以最大的吞吐量為下限來設計，原則是盡量能夠同時滿足盡量多的客戶，即播種墻的面積要大，如果有拍燈器，那麽拍燈器的數量要多，並且留下可以新增客戶的物理冗余。
工作站的形狀，常見的有L型，凹型，一型，應根據具體業務來具體設計。L型的播種墻，對操作人員最友善，最遠處也在操作人員半徑3米以內；凹型的工作站，適合和托盤結合，即三面播種墻是開放的，沒有格擋，揀貨時候貨物直接上托盤，操作人員可以在一步之內將比較重的貨物搬到托盤上；一字形的播種墻，占地面積最小（相同面積，一字形比L型更省空間），但是遠端播種墻距離操作人員過遠，走來走去的時間成本比較高(可以將揀貨點位放在中間位置，減少走動的時間消耗)。工作站的地板，應該距離地面有一定的高度，用來保護操作人員安全，防止機器人帶著貨架來到工作站時候壓到腳；另外有的貨架貨位比較高，沒有墊高，夠不到貨物，工作站底板正好可以增加人員位置高度。工作站需要給操作人員流出足夠的操作台面，用來臨時方一些包材，筆，其他掃描槍，飲水等等。
工作站和地圖銜接的位置就是揀貨點，這個位置需要使操作人員，貨架，印表機，顯視器，指示器，播種墻都處在最舒服的位置。通常來講，需要根據地圖來確定工作站的設計。工作站的位置，是影響揀貨效率的有一個關鍵因素。是否將所有工作站放在地圖的同一邊，需要考慮物料的流動特性。都放在同一邊，會增在工作站附近的堵車風險。但是放在不同位置，又會增加庫房面積的占用。
單行道，是在地圖面積緊張而機器人路徑規劃演算法又不能很好適應的情況下的妥協。在理想的情況下，機器人路徑規劃演算法應該可以完美的計算出最優路線. 但實際情況遠遠達不到完美。我們需要用設定單行道的方式在大範圍上維持一個可以迴圈起來的規則，即便犧牲些局部效率。由於單行道的存在，可以人為的控制堵車的點位，人為的區分開來回的路線；但是單行道必然會導致沒有最短路線，時間開銷將會變大。單行道的設定要謹慎，尤其是在沒有雙車道的情況下，因為一旦設定不當，機器人可有會繞很遠的路線，甚至會和演算法疊加之後出現死迴圈。
在不考慮成本的情況下，機器人總量是不是越多越好呢？不是。為了滿足峰值吞吐量需求，使用者往往會配置超量的機器人，但是一旦超過地圖合理的容量，會造成堵車。每一台機器人都需要占用一個地圖上一個位置，便是待命，也需要去充電，去充電的機器人在行進中就會占用其他有任務的機器人行動的路線。越多的機器人，會帶來越多的維護成本。如果有機器人掉線，也有可能卡住地圖點位，機器人越多，故障總量越大。判斷配置的機器人夠不夠，一個簡單的判斷方法是看有多少貨架可以一直在工作站排隊，最理想情況是每個工作站只有一個機器人在待命，就是這個地圖的最優機器人數量。
為了滿足任務的波動，必須要考慮等待佇列。那是我們前面提到的排隊邏輯。排隊的長度，太短，會造成供貨貨架銜接不上的情況，拖慢效率，太長，會造成機器人占用過多，浪費投資。如果解決方案可以按照實際的情況來動態調整排隊的長度是最好的，但是演算法難度不低。另外一個問題是能否按照一定的順序來排隊，在某些業務場景中，訂單會需要按照一定的順序來處理，那麽就意味著貨架需要按照一定的順序來排隊，這種情況會需要很多臨時點位用來做堆疊類別的排序。
值得進一步討論的是，當排隊足以滿足人員操作的情況下，想進一步提高揀貨效率，必須要提高人員揀貨這個環節的效率。貨架的切換是在這個環節的一個主要時間開銷，為了消除這個時間，可以考慮設定兩個排隊佇列，對應兩個相鄰的揀貨點位，兩個指示器，這樣貨架的切換時間可以被兩個貨架交替揀貨消除掉（和汽車雙離合變速器異曲同工）。
機器人的壁障邏輯，不同公司的產品有不同的傳感器，不同的演算法。在復雜環境下，壁障有可能出現過於敏感的現象，會將環境內正常的東西辨識成障礙物，比如起伏的地面，立柱等；不同的物體有對不同的傳感器有不同的反饋。壁障邏輯的及時性和準確性，是個相互矛盾的問題，為了保證安全，需要盡可能精確，但是一旦誤判，就會影響到路線的通常，卡住業務。小恐龍認為合理的解決方式是使用多模式辨識，即用一套最精確的配置參數作為基準，當發現疑似障礙物後，切換多種模式演算法和參數進行校驗。
本章節最後一個問題是充電。充電環節最重要的考慮就是一切都要安全。不同的地區有不同的法規，我們按比較嚴的的江浙地區作為案例來分析。首先用三元鋰電池的機器人是可以在庫房內使用的。但是充電有嚴格的規定，需要配置單獨的防爆充電間來進行隔離。防爆充電間可以用裝有防火門的封閉通道來連線庫區，爆炸壓力方向必須向室外。
在充電環境符合國家法規之後，我們首先要考慮的是充電過程的安全防護。為了保證充電效率，機器人公司會用大功率充電樁來充電，但是為了安全，在保證不大振幅影響效率的情況下，用低電壓（48V），低電流（不大於20A）來緩慢的充電是最安全的做法。大功率快充，會損壞機器人的鋰電池，造成火災風險。在機器人充電的控制邏輯上，需要一直對充電的電流保持監控，一旦發現微小的波動，馬上切斷充電，並不允許自動重新開機充電，並要及時報警，由人工介入處理。
充電的安全性，很大程度上依賴於充電機和機器人接駁的物理設計。由於充電電流有可能會很大，接駁的連線頭需要非常緊密的緊密，才不會產生電阻變大，過熱，著火的情況。但是緊密接觸，需要全固定的充電頭，這個對機器人和充電街頭對齊有挑戰（需要每台車去調教對齊）；且需要有比較大的接觸壓力，這個對機器人的電機有影響。目前有的先進機器人公司已經將硬接駁，透過在充電機上加單維度的活動桿，阻尼器，精密的齒輪來將硬連結轉化成半活動連線。這種連線方式是非常可取的安全設計，擁有這種充電機的公司，在供應商選型時候應該加分。
除了物理設計，充電的邏輯也是安全的關鍵組成部份。在設計上，機器人本身可以來主導充電控制，或者由充電樁來主導，每一家公司的設計會有很大差異。小恐龍的觀點是，系統越復雜，故障點會越多，故障率會越高，所以在結構上看，應該減少控制點。基於這種考慮，充電的控制端要放在充電樁或者機器人上，二者選一。如果將控制端放在機器人端，那麽充電樁就完全不需要被控制，不需要聯網，這樣從程式設計上，可以減少一個端，降低系統復雜度。不過這樣的設計，由於充電樁不聯網，那麽充電樁的設計，制造，充電接駁的設計要有高度可靠，這對機械加工提出了比較大的挑戰，成本會比價高。
在充電安全可以滿足的前提下，就需要提高充電效率，而充電策略比單個機器人充電的速度更重要。我們可以選擇的充電策略從滿沖滿放到快充一點就走都可以選擇。如果套用場景是前面提到的合單一波流，那麽在業務進行時段的使用壓力會很大，為了保證有最多的機器人在場上工作，且減小堵車問題，需要減少機器人充電的次數，而一旦去充電了，則充滿再出來。需要將充電閾值調的盡量低，而充滿閾值設定的盡量高；那麽在非高峰時段，可以將盡量多的機器人的電量保持在一定的閾值以上。
除了基本的充電策略按時間維度管理外，還可以考慮機器人的位置維度（在很大的地圖上，機器人從遠端去充電的時間開銷很大），任務，批次，電池型號等更多的優先級參數。
9）大無相功：IT基礎設施
無相，就是平時看不見摸不著，不會被註意到，但是一切的招式和技巧都需要以此為基石。在機器人實施的環境裏，我們指的是電，網和機房。這還是個問題？還真是，不用不知道，一用嚇一跳。
我們先談談電。首先就是電流總容量，機器人在使用中的充電總功率並不太大，但是電流很大，所以為了穩妥起見，需要配套一個比較大的配電櫃，電纜需要留出足夠的余量，來應對未來增加充電功率或者充電樁數量。其次，電壓要穩，由於物流庫房園區比較偏遠，尤其是新建的園區，整體供電的配套並不完善，在使用的初期，電壓會出現比較大的波動，這種電壓的波動，會影響網絡的穩定。
機器人方案對不間斷供電有很強的要求，一旦在某個環節停電，會對整套系統有破壞性影響，恢復起來非常花時間，有安全性風險。所以在電源設計上，UPS要對機房，網絡，WIFI，工作站有端到端的覆蓋。UPS的續航時間，需要足以支撐到園區發電機切換。UPS在選型的時候，要輸出功率大而輸入功率小（就是來電了之後慢慢沖不著急），否則會對電網有很大的沖擊。
再來談談重點，就是網絡。在設計機器人網絡的時候，我們需要按照7層網絡OSI模型來逐層討論。
首先是實體層。這個還有啥可討論的，其實影響機器人表現的網絡設計主要在這一層，但是常見的網絡工程師有最缺乏這個領域的知識，這一層的問題，應該找搞通訊的同學來搞定。我們先說說最常見的WIFI網絡，常用的WIFI頻段有2.4GHz和5GHz的區別，大家知道頻率越高，傳輸的距離越短，抗幹擾能力越差，所以通常來說2.4GHz的訊號傳輸效果應該比5GHz的效果好，但同時應該考慮到機器人的密度，即在一個AP覆蓋範圍內，最多會有多少台機器人，2.4G的通道太少，並不能滿足相對比較高的器材密度；與之相對，5GHz訊號技術的通道有13個，基本可以滿足器材連線，但是5GHz的訊號衰減更快，覆蓋距離更短，有的多天線的AP，使用了波束賦形的技術，可以是訊號的傳輸距離變長，波束賦形的無線訊號是有方指向性的，但是實際情況是機器人會被貨架和貨架裏面的金屬貨物遮擋，造成波束賦形技術效果有限（主要是對AP有要求，需要天線足夠多）。另外一個問題是AP路由問題，當機器人在不同的AP覆蓋區域切換的時候，有可能會掉線，卡頓，當然這個可以由機器人上層的程式設計來解決，各家有各家的方案，這是個大問題，解決不好，就會嚴重影響使用。
實體層另外一個方向就是5G技術。5G這個話題太大，我們在這裏只拋磚引玉的提一下。5G技術有三大方向：超大頻寬，超高密度，超可靠和超低延遲。在我們的場景裏，最優價值的是超可靠和超低延遲(uRLLC)。這種技術可以將網絡延遲控制在1ms以內(round-trip)，如果有了這種技術，那麽我們就可以將機器人的中心控制模組伺服器放在雲上，這樣就可以大大降低本地部署難度和成本，也能降低日常的管理維護難度。但是目前按照3GPP的路線圖來看，還需要好幾年才能夠實作(R16)，目前連技術標準都沒有定下來，所以還只是鏡中月水中花。在目前已經實作的5G技術裏面，可以考慮的技術是5G的新型天線技術和調制技術，比如MIMO和波束賦形。目前器材商已經開始嘗試園區內的私有部署，相對於傳統WIFI的優勢是單個天線覆蓋面積大，不需要切換器材，這樣就省去了機器人復雜的控制邏輯；同時減少室內的布線難度。在技術上已經沒有難度，但是商業上是否合算，仍然是個未知數。
剛才提到了，不穩定的電壓會影響網絡的穩定，這個問題也是小恐龍的親身經歷。電壓的變化會影響WIFI的表現，造成網絡實體層訊號不穩定，產生了大量的上層協定棧丟包重傳現象，影響了機器人的表現（思科器材，在這裏我必須吐槽一下。華為的器材沒有使用經驗）。在給WIFI加上了UPS之後，網絡問題就解決了，這是個意外發現，在任何關於網絡的課程上都沒有提及。
在實體層之上是數據鏈路層。需要討論的不是MAC層本身，而是基於這層的網絡安全。大家知道物流機器人和傳統AGV的區別就是內部有OS，可以自主處理復雜任務，這種OS在工業控制領域是及那麽幾種，那麽就意味著有可能被攻擊和滲透。而機器人本身對物理世界是會產生影響的，那麽意味著一旦行為不可控，危險程度比傳統伺服器更嚴重的多。所以機器人系統的安全設計是需要從底層就開始考慮的。我們在這裏不會討論機器人本身的控制體系和安全認證等級，只討論在網絡層面的問題，安全設計就要從MAC層開始。機器人端需要和伺服器端保持持續，高速，雙向，同步的連線，連線實作上就完全淘汰了互聯網常用的技術(https)，而使用的是老一代開發者無比熟悉的socket, 加密機制就需要用TLS，SSL這樣的技術。大家一般認為TLS加密技術是傳輸層技術，這沒有錯，只不過為了保護連線不被劫持，在實作上，對MAC層的包做了處理，加入了一些由4層計算之後的哈希演算法的結果，所以實際上是從MAC層就開始了保護。
不論何種形式的加密機制，都需要證書來作為根。那麽證書的分發就成為了關鍵的安全漏洞。目前來看，機器人的執行網絡還是基本都在企業內網，那麽證書的分發可以透過非加密方式發給機器人是可行的（雖然並不安全，但是單獨攻擊一台內網的機器人，經濟上並不劃算）。但是如果伺服器端是在雲端，那麽證書就需要提前內建到機器人OS裏面。目前各大廠商的IoT雲解決方案裏都有了端器材的加密和證書解決方案，比較完善，不過需要使用SDK。對於企業來說，機器人類別的有安全風險的端器材的安全管理，證書管理，註冊管理仍然需要摸索。
IP層需要討論的問題比較簡單，就是IP是不是要繫結。目前比較簡單可行的方式就是繫結IP地址，繫結之後，可以更容易的進行遠端的存取和管理，這點IT從業人員都了解，不必解釋。但是，一旦需要管理的機器人數量變多，那透過IP地址來管理機器人將會變得極其混亂，所以透過更上層的序號產生器制將機器人的編號和MAC繫結，作為管理清單是比較可行的，而IP完全可以隱藏下來（因為大企業的IP地址都是DHCP分配的，需要定期重新整理，即便是做了處理，仍然由很大可能出錯）。
傳輸層，我們一定要使用TCP而不是UDP，因為在網絡傳輸過程中，IP包有可能發生丟包和錯序，而如果使用UDP，去處理錯誤數據的機制就落在了套用層本身，時效性不允許，而TCP的話，可以有OS層的協定棧來自動處理，是最高效的方法。但是使用TCP協定棧的時候需要註意的是MTU的大小，在大型企業的網絡裏，MTU的協商機制有失效的可能（小恐龍有經驗，眼淚嘩嘩。。。）。不選UDP，有的同學會問，很多要求其延遲的遊戲也是UDP的，在套用層處理異常，也很好啊。這就是因為現實環境不允許短暫失控，而遊戲可以。
傳輸層的另外一個問題是路由。在一個高標準庫房裏，都會要求ISP雙線接入，一旦一條路線發生故障（比如光纜被挖掘機幹斷，這經常發生），下層網絡會自動切換到另外的路線。但是，這需要時間，在切換過程中，耗時最久的就是路由的重新建立（幾十秒），這段時間，機器人將會收到影響，為了避免機器人掉線，我們需要在套用上做合理的邏輯。
本章最後一個問題是機房. 這個問題是,機房到底要放在哪. 一般大型企業都會有數據中心, 按照這種公司又死又硬的所謂規定, 伺服器應該放在數據中心, 機器人的伺服器也不能例外. 那麽問題來了, 機器人和伺服器的數據傳輸是延遲敏感的, 目前行業一般的說法是延遲要在50ms一下,才可以保證機器人的效率. 如果我們的使用場景的位置距離伺服器超過了1300公裏, 那麽網絡上的延遲將會在50ms上下. 基於這樣的事實, 專業的物流公司會將伺服器就近部署 (不一定在庫房內,但是會是很近的數據中心). 但是一般的企業很可能不具備這樣的條件, 那麽職能將伺服器前置到庫房. 這將會增加建設和管理成本, 所以並不是一個長期的辦法. 目前來看,還是需要部署到雲上, 在解決了網絡傳輸質素的前提下.
上面這些內容是小恐龍這幾年來在庫房場景下的使用經驗，希望對大家有所幫助，並希望和業內專家多多交流。
