「機器人走到廠房後段就停住不動，要人去把它推回來。」這是我們在客戶現場最常聽到的抱怨之一。問題不在機器人，在網路——而網路死角，在設施裡是常態，不是例外。
工廠網路死角的現實
金屬貨架、沖床、天車、成排的機台，對 WiFi 訊號都是實體屏障。就算 AP 佈得再密，總有幾條走道、幾個轉角是訊號照不到的。對辦公室裝置來說，掉線幾秒沒人在意；但對一台正在執行多站搬運任務的 AMR 來說，掉線的那一刻，任務就懸在半空中。
要求客戶「先把全廠 WiFi 補好」聽起來合理，實務上卻常常不可行：佈線要停線施工、AP 要資安審核、有些區域本來就不允許增設網路設備。我們的結論是：與其要求環境遷就機器人，不如讓機器人不依賴環境。
為什麼多數 AMR 一斷網就趴
主流 AMR 系統的架構，是「大腦在伺服器、四肢在機器人」：中控伺服器（或雲端）負責任務排程與逐步下令，機器人端只執行單一動作指令。走到 A 點之後，下一步去哪，要等伺服器再說。
這個架構在連線正常時沒問題，一進死角就露餡：機器人完成當前動作後，收不到下一道指令，只能原地待命或回報失敗。任務狀態卡在「執行了一半」，伺服器看不到機器人，機器人也等不到伺服器——雙方都在等對方，而現場操作員只看到一台停在走道中間的機器人。解法也很直觀，把天線外露、能用兩根天線就不要用一根。在所有電子產品都做內藏天線的今天，機器人大概是少數會反其道而行的典範。
另外一個架構是機器人身上自己背著平板，主打完全可以離線運行。但等到機器人走出視線範圍，就沒有任何方法可以知道它的狀態了。
單站任務還能勉強閃過死角，「多站路線」幾乎必死：站點越多，路線越長，全程都有順暢網路的機會趨近於零。
我們的解法：把整條路線放進機器人本體
Sigma 的模式反過來做：派遣的瞬間，把整條路線——所有站點、停留邏輯、確認條件——即時寫出一支程式，部署到機器人本體內部執行。
Kachaka 機器人內建可執行使用者程式的 Playground 環境（原廠 Preferred Robotics 公開於 kachaka-api），我們的 Hub 透過 SSH 把路線執行腳本送上去之後，角色就轉換了：Hub 不再是逐步下令的中控，而是退到旁觀者位置；路線的推進完全由機器人上的腳本自主決定。
更重要的關鍵是，一旦機器人穿出死角、重新連上網路後，腳本再把各站的抵達與確認事件回報給主機補上紀錄；主機這端若伺服器重啟，也會自動重建狀態、把確實中斷的線上任務標記為中斷，不會留下幽靈任務。
能在局部離線、網路不穩定的狀態下執行「多站」路線並支援每站回報確認，這在業界是首創。
沒有網路，人跟機器人怎麼溝通？搖一下
上述方法解了「機器人怎麼收指令與回報」，還剩一個問題：到站之後，操作員怎麼告訴機器人「貨我取完了，你可以走了」？
沒有網路，App 按鈕、Web UI、無線按鈕全都失效。難不成要走回老路，在機器人身上再黏一片平板？我們最後選的介面，是機器人身上本來就有的感測器：IMU。操作員到站取完貨，徒手搖一下機器人車身，機器人偵測到搖晃，就前往下一站；路線走完，搖一下就回家。
這個設計有幾個好處：零額外硬體、零配對設定、零學習成本——「搖一下它就走」一句話就能教會任何產線人員；而且它是純本地的物理互動，跟網路狀態完全無關。
推跟搖怎麼分？
實作上真正的難題是誤判。現場有人會「推」機器人讓位，行駛與對接貨架本身也會產生可觀的加速度突波，這些都不能被當成確認信號。
我們採用了簡單卻穩定的演算法，讓機器人可以分得出來有人把它推走、跟有人正在搖晃它，並且可以避免在移動過程被觸發。
所以，機器人到位之後，操作員可以推著機器人到自己喜歡的地方，把東西拿起來放下去，然後搖一下機器人，它就會往下一站前進。
小結
離線多站路線沒有用到任何神奇的演算法，只是幾個務實的選擇：即時生成的路線邏輯下放到機器人本體、讓機器人自己回報任務狀態、透過機器人自己的感測器決定是否往下一站走。
設施不會為了機器人重佈網路，所以機器人得學會在沒有網路的地方，把事情做完。