什麼是 ROS2？為何要有 ROS2

2026-07-18
  • ros2
  • ros1
  • dds
  • middleware

問題定義

如果你在 2020 年之前開始學機器人軟體開發，第一個學的框架大概率是 ROS1。但如果你現在打開 ROS 官方文件或任何一門新課程，會發現所有新內容都在講 ROS2。這會讓人很自然地問：ROS1 到底出了什麼問題，非得重新設計一套新框架不可？

答案不是「ROS1 做得不好」，而是「ROS1 的核心架構，撐不住現在機器人產業實際需要的場景」——多機器人協作、嵌入式即時控制、跨網域部署。這些需求在 ROS1 設計的年代（2007 年前後）根本還不存在。

核心概念說明

ROS1 的根本限制：單點故障的 Master

ROS1 的通訊架構依賴一個叫 roscore 的中心化節點（Master）。每個節點啟動時都要向 Master 註冊自己，其他節點要發布或訂閱主題時，也要先問 Master「誰在監聽這個主題」。

這個設計簡單好懂，但有一個致命問題：Master 就是單點故障（single point of failure）。一旦 Master 程序掛掉，整個系統裡的節點就再也無法互相發現彼此——即使他們原本已經建立好的連線還能繼續運作，任何「新的」連線都建立不起來。對一台需要長時間穩定運行的機器人（例如工廠裡的移動機器人、戶外的巡邏機器人）來說，這是不能接受的風險。

ROS2 的解法：DDS 去中心化通訊

ROS2 把底層通訊機制整個換掉，改用工業界行之有年的 DDS（Data Distribution Service） 標準。DDS 最關鍵的特性是去中心化的節點發現機制（discovery）：節點之間透過多播（multicast）互相廣播自己的存在，不需要一個中心節點來仲裁。

這代表：

  • 沒有單一故障點，任何一個節點掛掉都不影響其他節點之間的通訊
  • 原生支援多機器人、跨網域（domain）的通訊隔離
  • DDS 本身是即時系統（real-time system）業界常用的標準，讓 ROS2 有機會用在對時序要求嚴格的場景（工業手臂、無人機飛控）

QoS：從「有沒有收到」到「用什麼方式收」

DDS 帶來的另一個重要能力是 QoS（Quality of Service）設定。ROS1 的主題通訊只有一種行為模式；ROS2 可以針對每個主題個別設定：

  • Reliability：訊息遺失時要不要重傳（reliable vs best_effort）
  • Durability：新加入的訂閱者要不要收到「加入之前」發布過的訊息（transient_local vs volatile）
  • History：要保留多少筆歷史訊息

舉例來說，感測器的即時資料流（例如雷射掃描）通常用 best_effort——訊息遺失就算了，反正下一筆很快就來；但機器人的地圖資料就會用 transient_local——確保晚加入的節點也能拿到目前的地圖，而不是只能等下一次更新。這部分在後面的 QoS 設定深入解析 會有專門的章節，這裡先知道「ROS2 的通訊行為是可以精細控制的」就好。

實作範例：確認你的環境是「真的能跑」的系統

在深入寫程式碼之前，ROS2 提供一個很好用的健檢指令，可以確認你的安裝與環境設定是否正常：

bash
ros2 doctor --report

在一個安裝正確的環境下，你會看到類似這樣的輸出（節錄關鍵區塊）：

text
ROS DISTRO           : lyrical
ROS VERSION           : 2
ROS DOMAIN ID         : 0 (default)
RMW MIDDLEWARE        : rmw_fastrtps_cpp

PLATFORM INFORMATION
    system            : Linux
    platform info     : Linux-6.8.0-lyrical-generic-x86_64-with-glibc2.39
    release           : 6.8.0-lyrical-generic

NETWORK CONFIGURATION
    interface name    : eth0
    ip address        : 192.168.1.42

TOPIC LIST
    /parameter_events
    /rosout

Please note that being 'OK' in the following results does not mean there is
no problem.
All Statuses:
    NETWORK CONFIG : OK
    PLATFORM       : OK
    QOS COMPATIBILITY LIST : OK
    RMW MIDDLEWARE : OK
    TOPIC LIST     : OK

看到最後幾行都是 OK，就代表你的 ROS2 環境（發行版設定、中介軟體、網路設定）沒有明顯異常，可以放心繼續往下走。如果 ros2 指令根本找不到，代表環境變數還沒設好，可以先參考 安裝與環境設置。

常見錯誤與除錯技巧

錯誤一：ros2: command not found

text
bash: ros2: command not found

原因：目前的終端機視窗還沒載入 ROS2 的環境變數（setup.bash）。ROS2 不像一般套件安裝後直接加進 PATH，每次開新的終端機都需要重新 source 一次。

排除方式：

bash
source /opt/ros/lyrical/setup.bash

如果不想每次開終端機都手動打這行，可以加進 ~/.bashrc：

bash
echo "source /opt/ros/lyrical/setup.bash" >> ~/.bashrc

錯誤二：兩台機器上的節點互相看不到彼此

現象：在同一個區網下，機器 A 的節點發布了主題，但機器 B 用 ros2 topic list 卻看不到。

常見原因：兩台機器的 ROS_DOMAIN_ID 設定不一樣。ROS2 用 domain ID 來隔離不同的 ROS2 系統（避免同個網路裡多組人的機器人互相干擾），如果沒有明確設定，預設值雖然都是 0，但只要有一方被改過（例如照著某篇教學設了 export ROS_DOMAIN_ID=30）而另一方沒改，兩邊就會處於不同的邏輯網路，完全看不到對方。

排除方式：確認兩台機器的環境變數一致：

bash
echo $ROS_DOMAIN_ID

兩邊回傳的數字要相同（或都沒設定、都是預設值）。

小結

ROS2 不是 ROS1 的介面翻新，而是把底層通訊機制換成去中心化的 DDS，解決了 ROS1「Master 是單點故障」的根本問題，同時帶來 QoS 精細控制、原生多機器人與即時系統支援。這些改變是接下來所有章節的地基——從下一節開始，我們會實際把環境架起來，寫出第一個能跑的 ROS2 節點。

延伸閱讀

常見問題

faq_01.log
ROS1 真的完全不能用了嗎？
ROS1 的最後一個發行版 Noetic Ninjemys 已經停止官方維護，代表不會再有安全性更新與新功能。既有系統還能繼續運作，但新專案幾乎不會再選 ROS1，長期維護的產品線也都在規劃遷移。
faq_02.log
ROS2 是不是比 ROS1 難學？
核心概念（節點、主題、服務）幾乎一樣，真正的差異在底層通訊機制與一些新增的模式（動作、生命週期節點、QoS）。如果你是從零開始學，直接學 ROS2 不會比學 ROS1 更難，還能省去之後遷移的成本。
faq_03.log
ROS2 可以跟 ROS1 混用嗎？
可以透過 ros1_bridge 讓兩者的節點互相通訊，通常用於漸進式遷移（部分子系統先換成 ROS2，舊系統暫時保留 ROS1）。但這只是過渡方案，不建議長期依賴。
faq_04.log
為什麼不是所有機器人公司都馬上換成 ROS2？
既有產品線如果已經用 ROS1 穩定運行多年，重寫整套系統的成本與風險都不小。多數公司採取的是「新專案用 ROS2、舊系統維持到自然汰換」的策略，而不是一次性遷移。