Occupancy Grid vs 點雲地圖：機器人建圖表示法該怎麼選

地圖不是只有一種畫法

機器人要在環境裡導航或操作，第一件事是把感測器收到的原始資料轉換成某種內部表示法，讓後續的路徑規劃、避障、操作決策模組能拿來運算。這個轉換過程存在不只一種合理選擇——Occupancy Grid（佔據網格地圖）與點雲（Point Cloud）地圖是最常見的兩種主流表示法，兩者服務的下游任務性質差異很大，理解這個差異，能更清楚看懂為什麼不同機器人系統的地圖模組長得完全不一樣。

Occupancy Grid：把空間切成方格，換取路徑規劃的效率

Occupancy Grid 把環境切割成固定大小的網格（常見解析度 5 到 10 公分見方），每個網格儲存一個數值，代表這個位置被障礙物佔據的機率——完全空曠是 0，確定有障礙物是 1，未探索區域則是不確定狀態。這種表示法最大的優勢是簡單直接：路徑規劃演算法（A*、Dijkstra，或本站在 Nav2 Costmap 與路徑規劃 一文中討論的全域與區域規劃器）可以直接在這張網格上運算最短路徑，不需要額外的幾何運算，資料結構也是固定大小的二維（或三維，如 octomap）陣列，記憶體用量可預期、存取速度快。

Occupancy Grid 的機率更新通常採用貝氏濾波（Bayesian filter）框架——每一次新的感測器觀測（例如 LIDAR 掃描到某個網格反射了雷射訊號）都會用對數勝算比（log-odds）形式累加到既有的網格機率估計上：

$$l_t = l_{t-1} + \log\frac{p(z_t \mid \text{occupied})}{p(z_t \mid \text{free})}$$

這個累加設計讓多次觀測能持續強化或修正單次觀測的雜訊誤差，也是為什麼佔據網格地圖在長時間運行後，對環境的估計會愈來愈穩定可靠，但代價是空間解析度受限於網格大小——想要更精細的環境細節，就必須用更小的網格尺寸，記憶體用量會隨網格數量呈平方（2D）甚至立方（3D）成長。

點雲：保留原始幾何細節，換取更高的資訊承載量

點雲直接把感測器（LIDAR 或深度相機）量測到的每一個反射點，以三維座標的形式儲存下來，不做任何空間離散化的簡化，因此能保留比 occupancy grid 精細得多的幾何細節——牆面的傾斜角度、物體的精確輪廓、桌面上小型物件的形狀，這些資訊在被壓縮成固定大小的網格時都會遺失或模糊化，但在點雲裡是完整保留的。

這種精細度正是本站抓取偵測系列論文導讀反覆用到的資料型態——Contact-GraspNet 直接以點雲作為輸入，把夾爪接觸點錨定在場景點雲的實際觀測點上；機械手臂做精細操作規劃時，也需要點雲提供的完整三維輪廓才能判斷夾爪能不能在特定角度接近物體而不會碰撞周遭環境。但點雲的資料量遠高於 occupancy grid——每秒鐘 LIDAR 或深度相機可能產生數萬到數十萬個點，如果不做任何降採樣或濾波處理直接餵給路徑規劃演算法，運算成本會遠高於在固定網格上搜尋路徑。

為什麼多數系統選擇兩者並存，而非二選一

實務上，多數服務於地面移動兼具機械手臂操作能力的機器人系統，並不會強迫整套系統只用單一種地圖表示法——2D 導航模組維護 occupancy grid（有時候會從 3D 點雲投影壓縮而來，只保留某個高度區間內的障礙物資訊），機械手臂避障與精細操作規劃模組則直接使用原始或稍加濾波的點雲，兩者各自服務不同層次的任務需求，這跟本站在點雲處理 PCL 教學文章中介紹的處理流程一致：同一份原始感測器資料，會依下游任務需求被處理成不同的中介表示法，而不是只產生一種「萬用地圖」讓所有模組共用。

選表示法的核心原則：資訊粒度要跟任務需求對齊

Occupancy Grid 與點雲的取捨，本質上跟本站在移動平台比較文章中討論的原則相通——沒有一種表示法能同時在資料精細度與運算效率上都勝出，關鍵是評估下游任務真正需要多細的資訊粒度。如果任務只需要回答「這塊地面能不能通過」，occupancy grid 用遠低於點雲的資料量就能給出足夠的答案；如果任務需要精確判斷物體幾何輪廓、規劃精細的接近角度，點雲提供的完整三維細節就是不能被壓縮犧牲的必要資訊。多數成熟的機器人系統選擇維護兩者並存，正是因為單一機器人往往同時要應付這兩類性質截然不同的任務需求。