機器人是一群小程式組成的團隊
打開一台運轉中的機器人內部的軟體，你不會看到一個龐大的程式，而會看到幾十個小程式，每個只做一件事：一個讀取攝影機，一個執行雷射掃描儀，一個決定往哪開，一個驅動車輪馬達，一個監視電池。它們同時執行，分布在一台或多台電腦上，並且不斷需要彼此的結果。攝影機程式拍下的畫面若沒人看得到就毫無用處；挑選路徑的程式若無法把方案交給馬達也同樣無用。
因此機器人軟體的核心問題不是某一個演算法，而是「管道」：所有這些程式如何快速、可靠、互不干擾地共享資料？為每個專案、每一次都手寫這套管道，既痛苦又容易出錯。一次性地為所有人解決這個問題的軟體層，叫做機器人中介軟體：一個位於眾多程式之間的共享通訊系統，讓它們能互傳訊息，而無需各自知道對方的網路位址。
ROS：人人都在用的共享管道
在研究界與工業界，迄今最常用的中介軟體是 機器人作業系統（ROS）。儘管名字如此，ROS 並不是像 Windows 或 Linux 那樣的作業系統——它執行在作業系統之上。更恰當的理解是：它是一套工具加上一組約定，用來構建機器人軟體堆疊：一種打包每個程式的方式、一種標準訊息格式（讓某家廠商的攝影機與另一家的規劃器彼此聽懂），以及把它們連接起來的通訊機制。
在 ROS 的術語裡，每個執行中的程式叫一個節點。攝影機驅動是一個節點；障礙偵測器是一個節點；馬達控制器是一個節點。整台機器人就是一張節點圖——這些小程式由它們之間流動的資料連成一張網。由於每個節點都說同樣的標準訊息，你可以替換其中一個、新增一個，或把某個節點搬到另一台電腦上，而不必重寫其餘部分。正是這種模組化，讓業餘愛好者和汽車公司能共用同一批積木。
ROS 還自帶可重用的部件，讓你不必從零開始：常見感測器的驅動、一棵座標變換樹（tf）（持續記錄機器人每個部件相對於其他部件的位置）、視覺化工具，以及為導航等任務準備好的現成軟體堆疊。上手 ROS，意味著繼承了一整個龐大社群經過檢驗的積木。
發佈—訂閱：簡報訂閱模型
節點究竟如何交換資料？其核心是發佈—訂閱模式。想像一份簡報：發佈者寫好一期，發到一個有名字的頻道上——比如「每週園藝貼士」。任何感興趣的人訂閱該頻道，就會自動收到每一期。發佈者無需知道讀者是誰、有多少、住在哪裡；讀者也無需四處去找發佈者。雙方唯一需要約定的，只有頻道的名字。
在 ROS 裡，這些有名字的頻道稱為話題（topic）。產出資料的節點是發佈者（publisher）；想要這份資料的節點是訂閱者（subscriber）。攝影機節點向一個名為 `/camera/image` 的話題發佈資料；障礙偵測節點訂閱 `/camera/image`，每一幀到達就立刻收到。同一批攝影機幀可以同時餵給好幾個訂閱者——錄製器、顯示器、偵測器——而發佈者無需任何額外工作。正是這種「解耦」，讓你能自由地增刪節點。
[camera node] --publishes--> /camera/image --+--> [obstacle detector]
|
+--> [video recorder]
|
+--> [live display]
one publisher, one topic, three subscribers — none know the others exist每塊拼圖插在哪裡：感知、規劃、控制
話題和節點只是佈線——在線纜裡流動的內容則遵循一種反覆出現的結構，叫感知—規劃—控制架構。感知把原始感測器資料變成對世界的理解（「前方兩公尺處有一堵牆」）。規劃決定如何應對（「左轉繞過去」）。控制把這個決定變成馬達能精確執行的指令。資料從感知流經思考、流入行動——隨後新的感測器讀數又開啟下一輪迴圈。
- 感知節點訂閱原始感測器話題（攝影機、光達），發佈處理後的結果——障礙地圖、偵測到的物體列表、對機器人位姿的估計。此處常透過感測器融合把多路資料流合併起來。
- 規劃節點訂閱這些感知輸出，再加上一個目標，然後發佈一條路徑或軌跡。此處常駐一棵行為樹，決定下一步該執行哪種行為。
- 控制節點訂閱規劃好的軌跡，並把底層指令——輪速、關節力矩——發佈到馬達驅動所監聽的話題上。這個迴路通常是所有迴路中跑得最快的。
這樣看來，架構與中介軟體就嚴絲合縫地對上了：感知、規劃、控制是一組組節點，它們之間的箭頭就是話題。在這一切接觸真實硬體之前，團隊會先用機器人模擬器測試整張節點圖——同樣的訊息、同樣的話題，只是機器人是虛擬的。由於節點只關心話題，它們分辨不出資料來自真攝影機還是模擬攝影機，這讓從模擬遷移到實體機器人變得格外順暢。
為何這種設計能勝出（以及要當心什麼）
這種「在中介軟體之上跑發佈/訂閱」的設計在三個大方面帶來回報。它模組化：各團隊可以獨立構建和測試節點。它可重用：一個寫得好的感知節點能原封不動地用到下一台機器人上。它還能跨越單機擴展——同樣的模式讓不同電腦、甚至不同機器人上的節點透過網路共享話題，這正是多台機器協同的多機器人系統的基礎。
它的權衡也值得了解。預設情況下，發佈/訂閱是「發完即不管」——發佈者並不知道是否有人收到訊息，因此丟失或遲到的資料可能在不知不覺中溜過去，必須在設計上加以防範。時序很重要：控制迴路若得不到新鮮的感測器訊息，可能變得不穩定。鬆耦合的節點也更難除錯，因為沒有任何單一位置能展示整條資料流——這正是 ROS 內建工具來記錄每一條訊息並稍後回放的原因，它把轉瞬即逝的故障變成可以從容研究的對象。