既然點雲能保留完整 3D 幾何細節，為什麼 Nav2 這類 2D 導航堆疊還是主要用 occupancy grid？

因為多數輪式機器人在室內導航時，真正需要回答的問題是「這塊地面能不能通過」而不是「這裡的物體長什麼精確形狀」，occupancy grid 把這個問題簡化成每個網格是否被佔據的二元（或機率）判斷，資料量遠小於點雲，路徑規劃演算法（如 A*、Dijkstra）也能直接在網格上運行，不需要額外的幾何處理步驟。點雲保留的完整 3D 細節，對地面導航機器人而言多數是用不到的冗餘資訊——天花板高度、牆面材質這些點雲會忠實記錄的資訊，對「能不能通過這塊地面」這個問題毫無幫助，這也是為什麼即使感測器（如 LIDAR）原始輸出是點雲，多數 2D 導航堆疊仍然會先把點雲投影壓縮成 occupancy grid 再做路徑規劃。

點雲地圖是不是只有需要處理 3D 場景的機器人才用得到？

主要是的，任何需要理解場景完整 3D 結構的任務——機械手臂避障規劃（需要知道障礙物在三維空間裡的精確輪廓，而不只是投影到地面的佔據範圍）、無人機在複雜三維空間中導航、或者本站抓取偵測系列文章中討論的物體幾何分析（Contact-GraspNet 這類方法直接以點雲作為輸入），都需要點雲承載的完整三維幾何資訊，2D occupancy grid 在這些場景裡資訊量明顯不足。反過來說，如果任務範圍侷限在地面移動的路徑規劃，點雲帶來的額外三維細節通常換不回對應的運算成本。

同一套系統可以同時維護 occupancy grid 跟點雲地圖嗎，這樣不會很浪費資源嗎？

可以，而且是相當常見的架構——很多實際部署的機器人系統會同時維護兩種表示法，各自服務不同的下游模組：occupancy grid 供 2D 路徑規劃與避障使用，點雲（或從點雲進一步處理出的三維佔據柵格 octomap）供需要完整三維資訊的模組（機械手臂避障、精細操作規劃）使用。這確實會增加記憶體用量與同步維護的工程複雜度，但相較於強迫所有下游模組共用同一種表示法、卻犧牲了各自真正需要的資訊粒度，維護兩種表示法通常是更務實的架構選擇，這也是為什麼本站在 Nav2 Costmap 與點雲處理 PCL 兩篇教學文章會分開介紹——它們服務的是同一套機器人系統裡不同層次的需求，而非互相替代的競爭方案。

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 用遠低於點雲的資料量就能給出足夠的答案；如果任務需要精確判斷物體幾何輪廓、規劃精細的接近角度，點雲提供的完整三維細節就是不能被壓縮犧牲的必要資訊。多數成熟的機器人系統選擇維護兩者並存，正是因為單一機器人往往同時要應付這兩類性質截然不同的任務需求。