ROS 2 核心概念

在開始執行任何指令之前，先把基本術語弄清楚會很有幫助。ROS 2（Robot Operating System 2）是一套軟體函式庫與開發慣例，用來將許多小型、彼此通訊的運算單元組合成機器人應用程式。本頁會介紹 ROS 2 的核心組成元素，更重要的是說明什麼情況下應該使用哪一種機制。

概述

ROS 2 系統可以視為一個由多個獨立 Node 組成的 Graph。這些 Node 透過幾種定義明確的通訊模式交換資料，包括 Topic、Service 與 Action。Node 也可以透過 Parameter 在執行期間進行設定。Node 之間傳遞的所有資料，都會透過 Interface（Message、Service 與 Action 定義）指定明確的型別。

Node A --topic--> Node B
Node C <--service--> Node D
Node E <--action (goal/feedback/result)--> Node F
Parameters live inside a node and configure its behavior

為什麼重要

在 ROS 2 專案中，選錯通訊模式是最常見的設計問題之一。若把 Sensor Stream 設計成不斷重複呼叫 Service，就會把持續產生的資料硬套進 Request/Response 模式，並可能不必要地阻塞 Client；如果把長時間執行的機器手臂動作設計成 Topic，則沒有內建方式回報任務完成狀態，也無法直接取消執行中的任務。

在一開始就了解每種通訊機制的適用情境，可以避免後續重新設計，尤其當你進一步進入 Mobility 與 Manipulation 時，這些功能通常會同時使用多種 ROS 2 通訊機制。

核心概念

Nodes

Node 是 ROS 2 中執行單一邏輯工作的運算單元，例如讀取 Camera、執行 Controller，或彙整 Diagnostic 資訊。Node 是 ROS 2 的基本組合單元：實際系統通常由許多較小的 Node 組成，而不是由單一大型程式完成所有工作。

• 每個 Node 都有自己的名稱，在同一個 ROS 2 Graph 中應盡量保持唯一。
• 多個 Node 可以透過 Composition 組合在同一個 OS Process 中，以提升效能；也可以分別執行在不同 Process 中，以提高隔離性。這是部署方式的選擇，不會改變 ROS 2 的基本程式設計模型。

適合使用 Node 的情況： 當你需要建立一個明確的運算或功能責任單元，例如 Driver、Algorithm 或 Coordinator。

Topics

Topic 使用 Publish/Subscribe 模式。Publisher 將 Message 發布到指定名稱的 Topic，而不需要知道是否有 Subscriber 正在接收；任意數量的 Subscriber 都可以接收這些資料。Topic 通訊是非同步的，而且通常是持續進行的。

• 適合串流資料，例如 Sensor Reading、Robot State 與持續性的 Command。
• 沒有內建的每筆 Message 確認機制；Publisher 不會知道某一筆 Message 是否已被接收或處理。
• 同一個 Topic 可以同時有多個 Publisher 與多個 Subscriber，只要使用相同的 Message Type。

適合使用 Topic 的情況： 資料會持續或週期性產生，而且每筆資料都不需要等待回覆，例如 /scan、/joint_states、/cmd_vel。

Services

Service 使用 Request/Response 模式。Client 發送 Request，並等待（或以非同步方式等待）Server 回傳一個 Response。

• 適合短時間、快速完成的操作，例如「取得一個值」、「切換模式」或「執行一次運算」。
• 從概念上來看，Service Call 會等待 Response 回來（或 Timeout），因此不適合執行時間很長或需要持續回報進度的任務。
• ROS 2 Service 通常設計成同一個 Service Name 對應一個 Server。應避免同時執行多個使用相同 Service Name 的 Server，因為 Request 可能會由不同 Server 處理，造成行為難以預測。

適合使用 Service 的情況： 當你需要一次 Request 與一次相對快速的 Response，例如「清除 Costmap」、「取得目前的 Parameter」或「觸發 Calibration 流程」。

Actions

Action 使用非同步、以 Goal 為核心的通訊模式，適合需要較長時間完成，並且可能需要進度回報或取消功能的任務。一個 Action Interaction 主要包含以下四個部分：

項目	用途
Goal	Client 發出的請求，用來描述希望執行的工作
Feedback	Goal 執行期間定期回報的進度資訊
Result	Goal 結束後回傳一次的最終結果
Cancel request	Client 要求提前停止仍在執行中的 Goal

Action 在內部是由 Topic 與 Service 組合而成，但在使用時應將它視為獨立的 ROS 2 通訊機制，並使用專屬的 Client / Server API。

適合使用 Action 的情況： 操作執行時間較長、需要進度回報，或必須支援取消，例如導航到指定 Pose，或執行 Joint Trajectory。

提示

ROS 2 Action 與 Manipulation 中的「Arm Action」

Manipulation 章節中的 Arm Action 使用「Arm Action」來描述 Manipulation Workflow 的一個執行階段，也就是把 Trajectory 傳送給 Robot，並監控執行狀態的部分。

它並不是本頁所介紹的 ROS 2 Action 通訊機制的同義詞，雖然這個 Workflow Stage 通常會在內部使用 ROS 2 Action，例如 control_msgs/action/FollowJointTrajectory。

請區分這兩個概念：一個是 ROS 2 的通訊模式，另一個是 Manipulation Pipeline 中的一個執行階段，只是該階段剛好通常使用 ROS 2 Action 來實作。

Parameters

Parameter 是存在於 Node 內部、具有名稱與型別的設定值，可用來調整 Node 的執行行為，而不需要修改程式碼。例如 Sensor 的 Frame ID、Control Loop 的更新頻率，或 Threshold Value。

• 可以在啟動時透過 Command Line、YAML File 或 Launch File 設定，也可以在 Node 執行期間修改（前提是該 Node 支援這種更新方式）。
• Parameter 屬於宣告它的 Node；ROS 2 沒有 ROS 1 那種全域 Parameter Server。

適合使用 Parameter 的情況： 某個值應該可以調整，而不需要修改或重新編譯原始碼。實作範例請參考 Parameter 與 Launch。

Interfaces (Messages, Services, Actions)

Interface 定義 Topic、Service 或 Action 所交換資料的結構。ROS 2 內建許多 Interface Package，例如 std_msgs、sensor_msgs、geometry_msgs 與 action_msgs，每個 Package 也都可以自行定義 .msg、.srv 或 .action 檔案。

• Message Interface（.msg）描述 Topic 傳遞的資料格式。
• Service Interface（.srv）描述 Request 與 Response。
• Action Interface（.action）描述 Goal、Result 與 Feedback。

通訊雙方必須使用完全相同的 Interface Type（Package 與 Type Name），否則無法彼此通訊。可參考 Troubleshooting 了解這類問題會如何發生。

The ROS 2 Graph

Graph 是 ROS 2 系統在執行期間的整體狀態圖，包含目前有哪些 Node、它們使用哪些 Topic / Service / Action，以及彼此之間如何連接。

Graph 是動態的，Node 可以隨時加入或離開，不需要手動設定中央 Registry。Discovery 會由底層 Middleware（DDS 或對應的 RMW Implementation）自動處理。

你可以使用 ros2 CLI 檢查 Graph（會在 CLI 基礎操作 中介紹），也可以使用 rqt_graph 以圖形化方式查看。

如何選擇正確的通訊機制 — 快速參考

需求	建議使用
持續傳送資料，不需要逐筆回覆	Topic
一次快速 Request、一次快速 Response	Service
長時間執行，並需要進度回報與取消	Action
執行期間可調整的設定值	Parameter
定義交換資料的格式	Interface（msg/srv/action）

實作步驟

本頁主要用來建立概念。若要在實際執行中的 ROS 2 系統中觀察這些內容：

1. 前往 CLI 基礎操作，列出執行中的 Node、Topic、Service 與 Action。
2. 完成 Publisher/Subscriber 的最小範例，實際觀察 Topic 通訊。
3. 在 Service 與 Action 中實際呼叫 Service，並送出 Action Goal。

預期成果

閱讀完本頁後，你應該能清楚說明某一項機器人資料為什麼應該使用 Topic、Service 或 Action，並理解 Parameter 是用來設定 Node 行為，而不是 Node 之間交換資料的通訊機制。

常用指令

# See the whole graph at a glance
ros2 node list
ros2 topic list -t
ros2 service list -t
ros2 action list -t
ros2 param list

Common Problems

• 「這應該使用 Topic 還是 Service？」 — 如果每一筆資料都需要 acknowledgement 或 return value，那通常比較適合使用 Service，而不是 Topic。
• 「我的 Action 一直沒有完成。」 — Action 需要有效的 Goal Handle 與 Result；如果 Client 只讀取 Feedback，卻沒有等待 Result，看起來就可能像是一直卡住。可參考 Service 與 Action。
• 「兩個 Node 使用相同的 Interface Name，為什麼還是不能通訊？」 — 名稱相同還不夠；Package 與 Type 必須完全一致。可參考 Troubleshooting。

重點整理

• Node 是 ROS 2 的運算單元；Topic、Service 與 Action 是 Node 之間的主要通訊方式。
• Topic：持續傳送資料，不需要逐筆回覆。Service：快速的一次 Request/Response。Action：適合長時間執行，並支援 Feedback 與取消。
• Parameter 用來設定 Node，不是 Node 之間的通訊 Channel。
• Interface 定義交換資料的精確結構，通訊雙方的 Type 必須完全一致。
• 「ROS 2 Action」（通訊機制）與「Arm Action」（Manipulation Workflow Stage）彼此相關，但代表不同概念。

下一步

接著前往 CLI 基礎操作，開始檢查一個實際執行中的 ROS 2 系統。