# micro-ROS 理論篇
## 一、ROS 2 架構
### 1. ROS 2 的設計理念與定位
ROS（Robot Operating System）最早是為了讓機器人開發更模組化而誕生的。
它不是傳統意義上的「作業系統」，而是一套**通訊框架與軟體生態**，
讓不同模組之間可以以標準化方式交換資料、共享資源、協同運作。
ROS 2 是 ROS 的第二代，最大的改革是將整個通訊底層改寫為 **DDS（Data Distribution Service）**。
這讓 ROS 2 能在不同平台上運行，也能支援更嚴格的即時性與可靠性需求。
ROS 2 的核心思想有三個：
1. **模組化（Modularity）**
系統由許多節點（Node）組成，每個節點只負責一件事。
節點之間不需要知道對方的細節，只需知道 Topic 名稱與訊息格式。
2. **分散式（Distributed）**
節點可以分散在不同裝置上，例如一個在電腦上、另一個在樹莓派上。
只要在同一個 DDS 網路中，節點就能互相發現並通訊。
3. **可重用性（Reusability）**
任何人寫的節點，只要遵守 ROS 訊息規範，就能被別的專案直接使用。
---
### 2. Node、Topic、Publisher、Subscriber 架構
#### (1) Node
Node 是 ROS 世界裡的「程式單元」。
你可以把它想成一個在 ROS 網路中執行的進程（process）。
每個 Node 都有自己的名稱與功能，例如：
| Node 名稱 | 功能 |
| ------------------ | ------ |
| `/camera_node` | 負責影像擷取 |
| `/motor_node` | 控制馬達轉速 |
| `/navigation_node` | 負責路徑規劃 |
所有 Node 都由 `rclpy`（Python）或 `rclcpp`（C++） 建立與管理。
---
#### (2) Topic
Topic 是 ROS 的「資料通道」。
它定義了一個訊息的主題名稱與格式。
節點之間透過發佈與訂閱 Topic 進行資料交換。
例如：
```
Topic: /sensor/temperature
Type: std_msgs/Float32
```
任何節點都可以發布這個 Topic，也可以同時有多個節點訂閱它。
---
#### (3) Publisher
Publisher 是負責「發送資料」的角色。
在 Python 中用 `create_publisher()` 建立。
基本語法：
```python
self.publisher = self.create_publisher(Float32, '/sensor/temperature', 10)
```
這段程式會：
* 宣告一個名為 `/sensor/temperature` 的 Topic
* 使用 `Float32` 訊息型別
* Queue 大小為 10（即緩衝最多 10 筆資料）
Publisher 會使用 `publish(msg)` 將資料送出。
---
#### (4) Subscriber
Subscriber 則是「接收資料」的一方。
它訂閱一個 Topic，並在每次收到新訊息時執行 callback 函式。
```python
self.subscription = self.create_subscription(Float32, '/sensor/temperature', self.listener_callback, 10)
```
其中：
* 第 1 個參數是訊息型別
* 第 2 個是 Topic 名稱
* 第 3 個是 callback 函式（當收到資料時執行）
* 第 4 個是 Queue 大小
Callback 函式格式通常如下：
```python
def listener_callback(self, msg):
self.get_logger().info(f'Received: {msg.data}')
```
這樣 ROS 2 節點就能被動接收並處理資料。
---
### 3. 通訊協定 DDS 的運作原理
DDS（Data Distribution Service）是 ROS 2 通訊的核心。
它是一種 **Publish–Subscribe 中介層協定**，專為分散式即時系統設計。
它的幾個特性：
1. **自動節點發現**
節點不需手動指定 IP 或 Port。
DDS 會自動偵測同一網路中的 Publisher 與 Subscriber，建立通訊連線。
2. **即時性與可靠性控制**
DDS 提供 QoS（Quality of Service）設定，讓使用者可以決定：
* 要不要保證資料送達
* 要保留幾筆歷史資料
* 延遲或頻寬的取捨
3. **去中心化（Decentralized）**
DDS 沒有中央伺服器。
所有節點都是平等的「Peer」，這讓系統更穩定，也容易擴展。
---
### 4. QoS（Quality of Service）設定
QoS 是 DDS 的關鍵機制之一，直接影響通訊的可靠度與效率。
常見參數如下：
| 參數名稱 | 意義 | 常用值 |
| ----------- | -------- | ------------------------------------------- |
| Reliability | 資料可靠度 | `Reliable`（保證送達） / `Best Effort`（允許丟包） |
| Durability | 是否保留舊資料 | `Volatile`（不保留） / `Transient Local`（保留最近一次） |
| History | 保留幾筆訊息 | `Keep Last`、`Keep All` |
| Depth | Queue 大小 | 數值，例如 10 |
範例：
```python
from rclpy.qos import QoSProfile, QoSReliabilityPolicy
qos = QoSProfile(depth=10)
qos.reliability = QoSReliabilityPolicy.RELIABLE
self.create_subscription(String, '/topic', self.cb, qos)
```
---
### 5. ROS 2 的優勢與限制
| 面向 | 優勢 | 限制 |
| --------- | -------------------------- | ---------------- |
| **可擴充性** | 支援多語言（Python / C++ / Java） | 效能取決於 DDS 實作 |
| **開發便利性** | 有完整 CLI 工具與 rqt 可視化 | 建構與依賴管理複雜 |
| **穩定性** | DDS 架構可靠、去中心化 | 高資源消耗（CPU / RAM） |
| **適用對象** | 桌上型機器人、工業自動化、AI 模組 | 無法直接用於 MCU 或裸機系統 |
這個「無法直接用於微控制器」的限制，就是 micro-ROS 出現的理由。
---
### 6. 為什麼 ROS 2 無法直接用於微控制器
原因主要有三點：
1. **記憶體限制**
DDS 的封包協定複雜，包含可靠性、封包重傳、緩衝佇列等機制。
一般微控制器（像 ESP32、STM32）只有幾百 KB 的 RAM，根本撐不住。
2. **作業系統依賴**
ROS 2 依賴 POSIX 系統呼叫（執行緒、定時器、socket）。
微控制器多數只有簡單的 RTOS 或無 OS，缺乏這些 API。
3. **效能與即時性問題**
ROS 2 是設計給多進程、非即時環境。
在 MCU 上，任務需要硬即時反應（例如 PWM 控制、感測中斷），
ROS 2 太「重」而且延遲過高。
因此需要一個「**具 ROS 2 通訊相容性，但能跑在微控制器**」的框架——這就是 micro-ROS。
---
### 7. 小結
ROS 2 解決了機器人開發的軟體協作問題，但它面向的是運算力夠的主機或 SBC（Single Board Computer）。
它提供完整的通訊功能，但在邊緣設備上代價太高。
接下來，micro-ROS 的角色就是：
> 把 ROS 2 的溝通能力延伸到記憶體幾百 KB 的小板子上，
> 讓「前線感測」與「後端運算」能講同一種語言。
---
## 二、micro-ROS 架構與設計理念
### 1. micro-ROS 的誕生背景
ROS 2 是個強大的框架，但它的前提是「主機」：
有作業系統、有網路堆疊、有記憶體，能跑 DDS。
可是現實裡，大量的機器人與 IoT 應用都依賴 **微控制器（MCU）**：
ESP32、STM32、LinkIt 7697、Arduino…
它們的記憶體只有幾百 KB、運算力不到主機的千分之一。
問題在於：
> 這些小板子負責了機器人最關鍵的「感測」與「控制」，
> 卻無法直接參與 ROS 2 生態系。
於是，**micro-ROS（micro Robot Operating System）** 應運而生。
它由多個歐洲研究單位（如 eProsima、Bosch、Acutronic Robotics）與 ROS 2 官方共同開發，
目標是將 ROS 2 的通訊架構「縮小」到能在 MCU 上執行，
同時保持 **介面相容、資料結構一致、通訊可互通**。
換句話說：
> micro-ROS 是 ROS 2 的「嵌入式延伸層」。
---
### 2. micro-ROS 與 ROS 2 的整合概念
micro-ROS 並不是獨立的新系統，而是 ROS 2 的子集。
它的運作理念非常明確：
「讓微控制器成為 ROS 2 網路中的節點（Node）」。
整體結構可用這張關係圖表示：
```
[ Microcontroller (ESP32 / STM32) ]
↑ Micro XRCE-DDS
│
[ micro-ROS Agent (Ubuntu / Jetson) ]
↓ DDS
[ ROS 2 Network (Host PC) ]
```
* **Client（micro-ROS Node）**：跑在 MCU 上，使用簡化版 ROS 2 API。
* **Agent**：跑在主機端，負責協定轉換（Micro XRCE-DDS ↔ DDS）。
* **Host Node（ROS 2 節點）**：跑在 ROS 2 網路中，與 Agent 通訊。
這樣設計的好處是：
* 保留 ROS 2 的生態（msg 格式、topic、service）
* 減輕 MCU 的負擔，通訊邏輯交給 Agent 處理
* 讓小裝置可以無縫加入 ROS 2 網路
---
### 3. micro-ROS 的架構分層
micro-ROS 不是「一個程式」，而是一整個堆疊（stack），
設計時考慮到即時系統、跨平台與資源受限等限制。
以下是 micro-ROS 軟體堆疊的典型結構（由下而上）：
```
+-----------------------------------+
| micro-ROS Application Layer | ← 開發者撰寫的應用程式（C / Python）
+-----------------------------------+
| RCL / RCLC Layer | ← ROS Client Library（簡化的 API）
+-----------------------------------+
| RMW (ROS Middleware) Interface | ← 連接到 XRCE-DDS 通訊層
+-----------------------------------+
| Micro XRCE-DDS Client Stack | ← 負責封包編碼與傳輸協定
+-----------------------------------+
| Transport Layer (UART / UDP) | ← 實體通訊界面
+-----------------------------------+
| RTOS / Hardware Abstraction | ← FreeRTOS / Zephyr / Arduino Core
+-----------------------------------+
| MCU Hardware |
+-----------------------------------+
```
#### 說明：
* **Application Layer**：你寫的程式碼。
就像 ROS 2 節點，但用的是 micro-ROS API。
* **RCL / RCLC**：ROS Client Library（C 版本為 `rclc`）。
提供建立 Node、Publisher、Subscriber 的函式。
* **RMW Interface**：中介層，連接 micro-ROS 與 XRCE-DDS。
* **Micro XRCE-DDS Client**：真正處理封包傳輸與序列化。
* **Transport Layer**：決定通訊方式（UDP、Serial、Wi-Fi）。
* **RTOS**：確保即時任務能正常執行。
這樣設計讓 micro-ROS 在任何支援 FreeRTOS 的晶片上都能執行。
---
### 4. Micro XRCE-DDS 通訊協定
micro-ROS 採用 **Micro XRCE-DDS（Micro Extremely Resource Constrained Environment DDS）** 作為通訊核心。
它是 DDS 的精簡版，由 eProsima 公司開發，專門給微控制器使用。
#### (1) 名稱解釋
* **XRCE**：代表「資源極度受限環境」。
* **DDS**：延續 ROS 2 的資料分配協定理念。
#### (2) 運作方式
在 ROS 2 中，節點之間透過 DDS 直接通訊。
但在 micro-ROS，MCU 不具備 DDS 功能，因此它的通訊是「代理式」的：
```
Client (MCU) --XRCE-DDS--> Agent --DDS--> ROS 2 節點
```
Client 不直接與 ROS 2 節點連線，而是向 Agent 發送 XRCE 封包。
Agent 解析封包後，再用標準 DDS 向 ROS 2 節點轉送。
這樣做的好處：
* MCU 不必理解 DDS 的完整協定。
* 封包輕量化，節省記憶體與頻寬。
* Agent 可以服務多個 micro-ROS Client。
#### (3) 傳輸協定支援
Micro XRCE-DDS 可搭配多種傳輸介面：
| 介面 | 使用情境 |
| ------------- | ------------------------------ |
| UDP | 主機與 MCU 連線穩定（Wi-Fi / Ethernet） |
| Serial (UART) | 有線連接，速率穩定、低延遲 |
| CAN / SPI | 工業應用或多控制板串接 |
| USB | 高速傳輸或除錯使用 |
---
### 5. micro-ROS Client、Agent、Host 的角色分工
#### (1) micro-ROS Client（跑在 MCU）
* 執行使用者程式
* 包含 Node、Publisher、Subscriber
* 使用 micro-ROS API（`rclc`、`rclpy`）
* 將所有封包送給 Agent 處理
#### (2) micro-ROS Agent（跑在主機）
* 負責連接 MCU 與 ROS 2
* 解析 XRCE-DDS 封包
* 使用 DDS 協定與 ROS 2 節點通訊
* 可同時服務多個 Client
* 常駐執行指令範例：
```bash
micro-ros-agent udp4 --port 8888 -v6
```
#### (3) ROS 2 Host Node（主機端節點）
* 普通的 ROS 2 節點，無須修改。
* 透過 DDS 與 Agent 通訊，就能收到 MCU 發來的資料。
#### (4) 範例流程：
以「溫度感測」為例：
```
[ ESP32 + DHT11 Sensor ] → micro-ROS Client 發布 Topic /sensor/temperature
↓
[ micro-ROS Agent ] → 轉為 DDS 封包 → 傳入 ROS 2 Topic
↓
[ Ubuntu ROS 2 Node ] → 訂閱 /sensor/temperature → 顯示數值
```
---
### 6. 為什麼 micro-ROS 能跑在微控制器上
micro-ROS 能夠在 MCU 上生存，是因為它的核心架構針對三件事徹底優化：
#### (1) 記憶體使用極低
* 移除 ROS 2 的動態記憶體配置與 XML 解析。
* 採固定緩衝區（Static buffer allocation）。
* 封包結構簡化，不支援所有 DDS 功能，但保留主要的 Publish-Subscribe 功能。
#### (2) 執行緒與 RTOS 整合
* ROS 2 原生使用多執行緒架構；micro-ROS 改為單任務 + callback 事件。
* 與 FreeRTOS 整合，可在 Task 裡運行 rclc executor（相當於 ROS 2 的 spin loop）。
* 支援任務排程、定時器與中斷。
#### (3) 封包序列化與壓縮
* 使用 XRCE-DDS 的二進位封包格式（比 DDS 小約 80%）。
* 內建 eProsima Fast CDR 序列化函式庫（極低延遲）。
#### (4) 運行環境靈活
* micro-ROS 可在 FreeRTOS、Zephyr、Nuttx、Arduino Core 執行。
* 同時支援 Wi-Fi、Ethernet、UART、USB 等傳輸介面。
---
### 7. micro-ROS 的設計理念小結
micro-ROS 的核心哲學，可以用一句話總結：
> “Bring ROS 2 to microcontrollers.”
> —— 讓最前線的感測與控制節點，直接融入 ROS 生態。
它不是取代 ROS 2，而是延伸它的邊界。
它的存在意義在於：
* 讓每個感測器、馬達控制器都能變成 ROS 節點
* 讓主機不必處理底層硬體
* 讓分散式機器人系統的所有裝置都說「同一種語言」
---
### 8. micro-ROS 與 ROS 2 的對應關係表
| 概念 | 在 ROS 2 中 | 在 micro-ROS 中 | 備註 |
| --------- | ----------------------- | --------------------------- | ----------- |
| 節點（Node） | `rclpy` / `rclcpp` 節點 | `rclc` 節點 | 功能相同但實作簡化 |
| 通訊協定 | DDS | Micro XRCE-DDS | 透過 Agent 轉換 |
| 執行環境 | Linux / Windows / macOS | FreeRTOS / Zephyr / Arduino | 無 OS 亦可 |
| 資料型別 | std_msgs / sensor_msgs | 相容 ROS 2 格式 | IDL 編譯支援 |
| Executor | 多執行緒 spin | 單執行緒事件排程 | 簡化版本 |
| Launch 機制 | `.launch.py` | 不支援（需手動啟動） | MCU 不具備作業系統 |
---
### 9. micro-ROS 架構視覺化概覽
```
+----------------------------+
| ROS 2 Network |
| (DDS, Python, C++, etc.) |
+-------------+--------------+
↑
│ DDS
│
+-------------+--------------+
| micro-ROS Agent |
| (Translate XRCE-DDS→DDS) |
+-------------+--------------+
↑
│ XRCE-DDS
│
+-------------+--------------+
| micro-ROS Client (MCU) |
| Node + Publisher + RTOS API|
+----------------------------+
```
這張圖是理解 micro-ROS 最關鍵的思維：
**Agent 是橋梁，Client 是節點，Host 是大腦。**
---
### 10. 小結：從架構理解 micro-ROS 的價值
* **角色定位明確：**
micro-ROS 是「邊緣節點框架」，專注感測與控制。
* **與 ROS 2 完全兼容：**
使用相同的訊息格式與通訊模型。
* **技術本質：**
不是全新作業系統，而是 ROS 2 的輕量延伸層。
* **開發意義：**
讓開發者能在 MCU 上使用熟悉的 ROS API，
不需再重寫感測器通訊協定或手動管理 UART 資料流。
---
## 三、資料流與封包傳輸
### 1. 概述：micro-ROS 資料流的全貌
在 micro-ROS 系統裡，資料不是「直接」從一個節點傳到另一個節點。
它要經過一整套橋接與轉換流程，才能讓主機端 ROS 2 節點理解。
最簡化的流程是這樣的：
```
[ micro-ROS Client (MCU) ]
↓ (Micro XRCE-DDS)
[ micro-ROS Agent ]
↓ (DDS)
[ ROS 2 Node (Host) ]
```
這三層分別扮演：
* **Client**：產生或接收資料（Publisher / Subscriber）
* **Agent**：轉換協定，管理通訊狀態
* **Host Node**：執行 ROS 2 處理邏輯（分析、視覺化、控制）
micro-ROS 的傳輸機制是「半雙工」的：
MCU → Agent 是 XRCE-DDS 封包；
Agent → Host 是 DDS 封包。
這樣的設計可以讓每個環節都專注於自己擅長的事：
MCU 管理感測與即時控制、Agent 處理封包翻譯、Host 專注高階運算。
---
### 2. XRCE-DDS 封包的角色與結構
在 ROS 2 中，DDS 封包本身包含非常多控制資訊：可靠性、時間戳、優先權、歷史緩衝等。
這在 MCU 上太重。micro-ROS 因此改用 **Micro XRCE-DDS** 協定。
XRCE-DDS 的核心概念是「Client–Agent 模型」。
#### (1) Client–Agent 模式
* **Client**（在 MCU 上）只需要知道：
* 我要發送哪個 Topic
* 我要接收哪個 Topic
* 封包資料（payload）
* **Agent**（在主機上）負責：
* 解析 XRCE 封包
* 轉成 DDS 封包
* 發布到 ROS 2 Topic
* 把 ROS 2 的回應再轉回 XRCE 封包給 MCU
這樣 MCU 端可以只保存「極少量狀態資訊」，通常不超過幾 KB。
#### (2) XRCE 封包結構簡介
XRCE 封包非常精簡，一個封包大致長這樣（概念化後的欄位）：
| 欄位 | 功能 |
| --------------- | ----------------------------- |
| `header` | 封包標頭，含 Client ID、Session ID |
| `submessage_id` | 表示封包類型（CREATE, WRITE, READ 等） |
| `object_id` | 對應的 Publisher / Subscriber 物件 |
| `payload` | 實際傳輸的資料內容 |
| `crc` | 檢查碼（確保資料完整性） |
範例概念：
```
Header [Client=0x01, Session=0x02]
Submessage: WRITE_DATA
Object_ID: Publisher_1
Payload: "temperature=26.4"
CRC: 0xA3
```
Agent 收到後，會把這個 payload 解析出訊息內容，再封裝成 DDS 格式發布。
---
### 3. 資料流實例：Ping-Pong 傳輸路徑
這是一個最經典的 micro-ROS 測試範例：
Client 傳送「ping」，Host 回傳「pong」。
透過這個例子，我們可以完整看一次資料流。
#### (1) Client 端（MCU）
1. 使用 micro-ROS API 建立 Publisher：
`create_publisher(String, "/microROS/ping", 10)`
2. 將字串 "ping #1" 打包成 XRCE-DDS 封包。
3. 封包經由 UART / UDP 傳給 Agent。
#### (2) Agent
1. 收到封包 → 確認 Client ID。
2. 解析出 Topic `/microROS/ping`。
3. 將 payload 轉成 DDS 格式，發布到 ROS 2 Network。
#### (3) Host（ROS 2 節點）
1. 收到 `/microROS/ping` 的訊息。
2. 執行 callback：回傳 `/microROS/pong`。
3. ROS 2 節點使用 DDS 封包發布回應。
#### (4) Agent（回傳階段）
1. 接收 `/microROS/pong` 的 DDS 封包。
2. 將其轉回 XRCE-DDS 格式。
3. 發送回 MCU Client。
#### (5) Client（接收）
1. micro-ROS 解析 XRCE-DDS 封包。
2. 呼叫 callback 顯示結果：
```
[Client] Received: pong for ping #1
```
---
### 4. 資料流的四個階段
整個 micro-ROS 的資料傳輸，可以明確分成以下四個階段：
| 階段 | 發送者 | 接收者 | 協定 | 備註 |
| ------- | ---------------- | ---------------- | -------------- | --------------- |
| Stage 1 | micro-ROS Client | micro-ROS Agent | Micro XRCE-DDS | MCU 發送感測資料 |
| Stage 2 | micro-ROS Agent | ROS 2 Network | DDS | Agent 轉換封包 |
| Stage 3 | ROS 2 Node | micro-ROS Agent | DDS | 主機節點回傳控制命令 |
| Stage 4 | micro-ROS Agent | micro-ROS Client | Micro XRCE-DDS | Agent 回傳封包至 MCU |
四個階段是雙向對應的，確保 MCU 與主機之間能同步狀態。
---
### 5. 節點命名與 Topic 對應規範
micro-ROS 完全遵守 ROS 2 的命名規則。
這保證了 micro-ROS 與 ROS 2 節點可以共用相同的命名空間與 Topic。
| 元素 | 規則 | 範例 |
| --------- | ---------------------- | ---------------------- |
| Node 名稱 | 只能用小寫字母、數字與底線 | `micro_sensor_node` |
| Topic 名稱 | 必須以 `/` 開頭 | `/sensor/temperature` |
| Namespace | 可用於分組 | `/robot/front_sensor` |
| QoS | 與 ROS 2 相同，可調整可靠性與緩衝大小 | Reliable / Best Effort |
若你在 MCU 上宣告：
```c
rclc_publisher_init_default(&publisher, &node, ... "/microROS/temp");
```
那在 ROS 2 主機上執行：
```bash
ros2 topic echo /microROS/temp
```
就能直接接收到來自 MCU 的資料。
---
### 6. Agent 如何管理多個 Client
micro-ROS Agent 並不是一對一的，它可以同時服務多個微控制器。
每個 Client 連線時都會被分配一個唯一 ID。
Agent 的工作模式如下：
1. 接收封包 → 讀取 Client ID
2. 驗證 Session 是否存在（若不存在則建立）
3. 維護 Client 狀態表：
* 活動中節點（Active Nodes）
* 已建立的 Publisher / Subscriber
* QoS 配置
4. 每當 Agent 收到 Client 封包，會查表找到對應 DDS 物件。
範例（Agent 狀態表概念）：
| Client ID | Node 名稱 | Topics 發布 | Topics 訂閱 |
| --------- | ------------- | ----------------- | ------------ |
| 0x01 | `temp_sensor` | `/sensor/temp` | - |
| 0x02 | `motor_ctrl` | `/motor/feedback` | `/motor/cmd` |
---
### 7. micro-ROS 傳輸層（Transport Layer）
micro-ROS 的靈活性來自它可替換的傳輸層。
根據應用情境，你可以選擇不同介面。
| 介面 | 特點 | 適用場合 |
| ----------------- | ---------- | ---------------- |
| **UDP** | 無線網路傳輸，速度快 | Wi-Fi / Ethernet |
| **Serial (UART)** | 有線、穩定、延遲低 | MCU ↔ 主機近距離連線 |
| **CAN** | 抗干擾能力強 | 車用、工業現場 |
| **USB** | 高速、除錯方便 | 開發階段 |
| **SPI/I2C** | 低速但簡單 | 板對板通訊 |
Transport 層與 XRCE-DDS 是獨立的，
只要提供收送封包的函式指標（`send()`, `recv()`），
micro-ROS 就能運作在任何介面上。
---
### 8. 資料封包轉換範例（深入流程）
以下是「MCU 發送資料 → 主機節點接收」的實際邏輯：
```
Step 1: MCU 端呼叫 publish()
↓
Step 2: rclc → RMW Interface → XRCE Client
↓
Step 3: XRCE Client 將資料序列化為 XRCE 封包
↓
Step 4: 傳送封包（UART/UDP）
↓
Step 5: Agent 接收 → 反序列化封包
↓
Step 6: Agent 轉換成 DDS 封包
↓
Step 7: DDS 通知 ROS 2 Node 有新資料
↓
Step 8: Node callback 執行，顯示或回應資料
```
整條路徑大約只需幾毫秒，取決於傳輸介面與封包大小。
---
### 9. micro-ROS 封包大小與效能
XRCE-DDS 封包大小通常在 50–150 bytes。
即使加上 header，也遠小於 ROS 2 DDS 的 1–2 KB 封包。
這意味著：
* micro-ROS 適合即時回報感測資料（高頻低量）
* 不適合大量影像或語音傳輸（封包過多會堵塞）
實際效能測試（ESP32 over UART）：
| 測試項目 | 效能 |
| ---- | ---------------- |
| 傳輸速率 | 約 10–20 msgs/sec |
| 平均延遲 | 約 40–80 ms |
| 最大封包 | 約 256 bytes |
---
### 10. micro-ROS 的資料同步與錯誤修復
micro-ROS Agent 會在通訊過程中自動維護 session 狀態。
如果封包丟失或 Client 掛掉，Agent 會在下一次封包時觸發重建程序。
具體行為包括：
* **心跳（Heartbeat）機制**：Agent 定期確認 Client 是否仍存活。
* **重傳（Retransmit）機制**：若 CRC 檢查失敗或 timeout，會重新請求封包。
* **Session 重建**：若 Client 重新上線，Agent 可根據先前設定快速恢復。
這些機制確保即使在不穩定連線下（例如 Wi-Fi），
micro-ROS 仍能保持通訊穩定。
---
### 11. 多 Topic 與多節點資料流整合
micro-ROS Client 可同時管理多個 Topic：
```c
rclc_publisher_init_default(&pub_temp, &node, ..., "/sensor/temp");
rclc_publisher_init_default(&pub_humid, &node, ..., "/sensor/humid");
```
Agent 會在 DDS 網路中註冊多個 Publisher，並同步更新。
在主機上，你可以同時監看多個資料流：
```bash
ros2 topic echo /sensor/temp
ros2 topic echo /sensor/humid
```
這讓 micro-ROS 不只是單一感測器節點，而是「多感測模組」。
例如一個 MCU 同時管理溫度、濕度、光照感測器，
每個感測值對應不同 Topic。
---
### 12. micro-ROS 資料流總結
完整的 micro-ROS 傳輸循環：
```
MCU publish → XRCE-DDS serialize → Agent translate → DDS publish →
Host Node receive → DDS reply → Agent translate back → MCU receive
```
| 層級 | 協定 | 主要任務 |
| ---------- | ----------------- | ------- |
| MCU | Micro XRCE-DDS | 封包產生與接收 |
| Agent | XRCE-DDS ↔ DDS 轉換 | 封包解析與轉發 |
| ROS 2 Node | DDS | 資料處理與回應 |
核心理念：
> MCU 不需要懂 DDS，但仍能參與 DDS 網路。
> micro-ROS 讓它透過 Agent「說出 ROS 的語言」。
---
### 13. 小結：資料流背後的意義
micro-ROS 的傳輸機制展現出一種「角色分離」的設計哲學：
* **MCU：** 專注於「產生資料」。
* **Agent：** 專注於「轉譯資料」。
* **Host：** 專注於「理解資料」。
這個模型讓微控制器能以最小負擔參與複雜的分散式系統。
資料從感測端一路穿過 Agent 到主機，再回到控制端，
形成一個完整的閉環（closed loop）。
這也是 ROS 2 與 micro-ROS 能在現代機器人、IoT 與邊緣計算中共存的關鍵。
---
## 四、ROS 2 與 micro-ROS 的比較分析
### 1. 比較前的觀念整理
ROS 2 和 micro-ROS 不是競爭關係，而是「同一棵樹的不同枝幹」。
兩者共享相同的設計哲學──**分散式節點架構 + Publish/Subscribe 通訊模型**，
差別在於它們服務的硬體層級與資源環境。
| 層級 | 典型裝置 | 任務類型 |
| ------------- | -------------- | --------------- |
| **ROS 2** | 主機、Jetson、樹莓派 | 高階計算、AI 推論、任務協調 |
| **micro-ROS** | MCU、感測器板、驅動控制器 | 邊緣控制、即時感測、訊號處理 |
兩者透過 **micro-ROS Agent** 共享同一個通訊空間，使整體成為一個統一的 ROS 2 生態系。
---
### 2. 架構層級比較
#### (1) 總覽圖
```
+-------------------------------+
| ROS 2 Network |
| (DDS, rclpy/rclcpp Nodes) |
+---------------+---------------+
↑
DDS 封包
↑
+---------------+---------------+
| micro-ROS Agent |
| (DDS ↔ Micro XRCE-DDS) |
+---------------+---------------+
↑
XRCE-DDS 封包
↑
+---------------+---------------+
| micro-ROS Client (MCU) |
| (rclc API, RTOS, Sensors) |
+-------------------------------+
```
#### (2) 分層比較表
| 分層 | ROS 2 | micro-ROS |
| -------------- | ---------------------------- | --------------------------- |
| 應用層 | Node (Python/C++) | Node (C/C++) |
| Client Library | `rclpy` / `rclcpp` | `rclc` / `rcl` |
| Middleware | DDS (Fast RTPS, Cyclone DDS) | Micro XRCE-DDS |
| 傳輸層 | TCP/UDP | UART/UDP/SPI/CAN |
| 作業系統 | Linux / Windows | FreeRTOS / Zephyr / Arduino |
| 資源需求 | 高（>512 MB RAM） | 極低（<512 KB RAM） |
---
### 3. 通訊協定差異
#### ROS 2：DDS（Data Distribution Service）
* **全功能分散式協定**。
* 節點自動發現 (Discovery)。
* 支援多種 QoS 與安全機制。
* 適合大型系統、高頻資料流。
#### micro-ROS：Micro XRCE-DDS
* **輕量化代理式通訊**。
* 以 **Client–Agent** 結構取代節點間直接互聯。
* 省去 Discovery、Security 等複雜程序。
* MCU 只需負責封包生成與解析，計算負擔極低。
| 面向 | DDS | Micro XRCE-DDS |
| ----- | ------------ | -------------- |
| 模式 | Peer-to-Peer | Client–Agent |
| 資料可靠性 | 完整 QoS 支援 | 精簡 QoS |
| 節點發現 | 自動 | 由 Agent 管理 |
| 封包大小 | 1 KB–2 KB | 約 50–150 bytes |
| 通訊負擔 | 高 | 極低 |
---
### 4. 開發環境與工具鏈比較
| 項目 | ROS 2 | micro-ROS |
| ---- | --------------------------------------- | ---------------------------- |
| 建構工具 | `colcon`, `ament_cmake`, `ament_python` | `colcon` + `micro_ros_setup` |
| 套件管理 | `rosdep`, `rosinstall` | 同 ROS 2 架構 |
| 編譯平台 | 原生編譯 (x86/ARM64) | 交叉編譯 (arm-none-eabi gcc) |
| 開發語言 | Python / C++ | C (支援 C++) |
| 啟動方式 | `ros2 run`, launch file | 在 MCU 初始化函式中呼叫 |
| 除錯方式 | rqt、CLI、rviz | UART log、Agent verbose 模式 |
| 模擬測試 | Gazebo / RViz | 可在 Ubuntu 模擬 Client 節點 |
micro-ROS 保持與 ROS 2 幾乎相同的建構邏輯，
讓開發者能用熟悉的 colcon 環境同時管理兩邊專案。
---
### 5. 效能與資源比較
| 指標 | ROS 2 (Node on Linux) | micro-ROS (Node on MCU) |
| ------ | --------------------- | ----------------------- |
| 記憶體需求 | 約 300–800 MB | 約 100–400 KB |
| CPU 負載 | 中高 | 低 |
| 平均延遲 | < 10 ms (UDP) | 40–100 ms (UART) |
| 最大封包 | 幾 MB | 256 bytes |
| 可連線節點數 | 幾百個 | 受 Agent 管理限制（數十個） |
| 即時性 | 軟即時 | 硬即時（依 RTOS） |
ROS 2 側重「吞吐量」；micro-ROS 側重「可預測性與低資源消耗」。
---
### 6. 應用定位與系統角色
| 系統層級 | ROS 2 的角色 | micro-ROS 的角色 |
| ------------ | ----------------- | ------------- |
| **上層：任務決策** | AI 模型推論、路徑規劃、資料分析 | 不適用 |
| **中層：通訊協調** | 節點間整合、狀態監控 | 透過 Agent 介入 |
| **下層：感測與控制** | 需外部控制板協助 | 直接運行在 MCU |
在真實系統裡，常見的結構是：
```
AI/Decision (ROS 2) → Control Command Topic
↓
micro-ROS Client (MCU)
↓
Sensor Feedback Topic → ROS 2 Monitor
```
---
### 7. 功能取捨與相容性分析
| 功能 | ROS 2 | micro-ROS | 備註 |
| ---------------------- | --------- | ---------- | --------------------- |
| Publisher / Subscriber | ✔ | ✔ | 完全相容 |
| Service | ✔ | ✔ | 支援但功能有限 |
| Action | ✔ | ✖ | 尚未支援 |
| Parameter Server | ✔ | ✖ | 不實作 |
| Launch System | ✔ | ✖ | MCU 無 OS |
| QoS | 全面支援 | 精簡版 | 僅 Reliability / Depth |
| Discovery | 自動 | 由 Agent 管理 | 無廣播負擔 |
| Security | 可擴充 | ✖ | 無安全層 |
| Diagnostics | rqt / CLI | 需自訂 | 由 Host 負責 |
這些差異說明了：micro-ROS 著重在「能運作」，而非「功能齊全」。
---
### 8. 實際整合案例
#### 案例 1：智慧小車
* 主機 (Jetson Nano)：ROS 2 節點負責影像辨識與路徑規劃。
* 子板 (STM32 + FreeRTOS)：micro-ROS Client 控制馬達、回報里程。
* 通訊介面：UART。
* 資料流：
```
/camera/image_raw → AI 處理節點
/cmd_vel → micro-ROS 控制節點
/odom ← micro-ROS 回傳節點
```
#### 案例 2：工業感測網
* MCU 節點各自感測溫度、壓力。
* 主機 ROS 2 節點彙整資料並視覺化。
* micro-ROS Agent 常駐主機，管理數十個 Client。
#### 案例 3：教育用途
* 用 ESP32 開發板搭建 micro-ROS Client。
* 學生在 Ubuntu 端用 Python 撰寫 ROS 2 Node。
* 即時看到感測值與回應命令。
---
### 9. 開發思維的轉換
在 ROS 2 裡，開發者思考「多模組協作」。
在 micro-ROS 裡，開發者思考「資源最佳化」。
| 思維 | ROS 2 | micro-ROS |
| ---- | ------------------ | -------------- |
| 任務重點 | 整體架構設計 | 單節點效率 |
| 程式習慣 | 多執行緒 / 大量 Callback | 單執行緒 / 簡化事件循環 |
| 錯誤處理 | 豐富例外處理機制 | 偏重穩定、靜態配置 |
| 測試方式 | 模擬與視覺化 | UART Log 與即時觀察 |
在嵌入式開發中，**每一筆記憶體配置、每一次封包傳輸都要被量化**。
這是 micro-ROS 開發與桌面級 ROS 2 最大的文化差異。
---
### 10. 綜合比較表
| 面向 | ROS 2 | micro-ROS | 差異核心 |
| ----- | ------------ | ----------------- | -------- |
| 通訊核心 | DDS | Micro XRCE-DDS | Agent 橋接 |
| 執行環境 | 高階作業系統 | RTOS / Bare Metal | 不同層級 |
| 程式語言 | Python / C++ | C / C++ | 語法層級 |
| 通訊模型 | Peer-to-Peer | Client–Agent | 架構差異 |
| 封包大小 | 大 | 小 | 資源配置 |
| 記憶體需求 | 高 | 低 | 適用平台 |
| 功能完整度 | 高 | 精簡 | 可用性 |
| 即時性 | 軟即時 | 硬即時 | 回應速度 |
| 擴充性 | 優 | 受限 | 平台差異 |
| 應用面 | AI、導航、雲端 | 感測、控制、IoT | 系統分工 |
---
### 11. 小結：兩者的共生關係
ROS 2 與 micro-ROS 的關係可以這樣總結：
> **ROS 2 是整體智慧的「中樞」，micro-ROS 是即時反應的「神經末梢」。**
它們在系統中各司其職：
* **ROS 2**：做決策、整合資料、提供全域控制。
* **micro-ROS**：負責接收感測、執行控制命令、即時回報。
兩者透過 Agent 橋接成一個閉環系統：
```
Decision (ROS 2)
↓ command
micro-ROS Client → Actuator
↑ feedback
```
這樣的架構讓大型機器人或 IoT 系統可以同時擁有：
* ROS 2 的彈性與資料處理能力，
* micro-ROS 的即時性與低耗能特性。
---
## 五、訊息型別與客製化通訊
### 1. 為什麼訊息型別很重要
在 ROS 2 / micro-ROS 世界裡，**訊息型別（Message Type）是節點之間通訊的共同語言**。
每個 Topic 都有固定的資料結構，
Publisher 和 Subscriber 只有在使用相同的訊息定義時才能理解彼此的封包內容。
範例：
```text
Topic: /sensor/temperature
Type: std_msgs/msg/Float32
```
Publisher 傳送一個 `Float32`，Subscriber 也必須用 `Float32` 接收，否則會報錯。
micro-ROS 與 ROS 2 在這點完全一致：
它們都使用 **IDL（Interface Definition Language）** 來定義訊息結構，
再透過編譯器自動生成 C / C++ / Python 對應的程式碼。
---
### 2. ROS 2 訊息定義的基本語法
在 ROS 2 中，訊息檔（`.msg`）是一種簡單結構定義格式。
範例：建立一個名為 `Temperature.msg` 的自訂型別：
```msg
float32 value
string unit
```
這代表每則訊息都有兩個欄位：
* 一個浮點數 `value`
* 一個字串 `unit`
ROS 在建置時會自動將 `.msg` 檔轉換為中介描述檔 `.idl`，
再進一步產生對應語言的類別（C、C++、Python）。
---
### 3. 訊息型別的轉譯流程
整個轉譯鏈如下：
```
Temperature.msg
↓
IDL (Interface Definition Language)
↓
C / C++ 結構定義
↓
micro-ROS 編譯結果 (micro_ros_msgs)
```
micro-ROS 會在編譯過程中讀取相同的 IDL 檔案，
因此 ROS 2 和 micro-ROS 兩端能共享相同結構。
---
### 4. ROS 2 標準訊息庫（std_msgs, sensor_msgs 等）
在一般應用裡，你不一定需要自訂訊息，
ROS 已經內建了數百種常用結構，
micro-ROS 也完全相容這些型別。
| 套件 | 說明 | 常見訊息 |
| ----------------- | ------ | ---------------------------- |
| `std_msgs` | 基礎資料型別 | Bool, Int32, Float32, String |
| `geometry_msgs` | 幾何資訊 | Vector3, Pose, Twist |
| `sensor_msgs` | 感測資料 | Imu, Image, LaserScan |
| `nav_msgs` | 導航資訊 | Odometry, Path |
| `diagnostic_msgs` | 狀態監控 | KeyValue, DiagnosticArray |
在 micro-ROS 中，這些型別都會在建置時自動轉換為 C 結構。
---
### 5. micro-ROS 對訊息的支援範圍
micro-ROS 可以使用任何「純資料結構（POD, Plain Old Data）」的型別。
但它**不支援動態記憶體分配或複雜容器**（例如 `std::vector`、`map`）。
支援範圍如下：
| 類型 | 支援狀態 | 備註 |
| ------------------------------ | ------- | ---------------------------- |
| 整數型（int8, int16, int32, int64） | ✔ | 全支援 |
| 浮點型（float32, float64） | ✔ | 全支援 |
| 布林值（bool） | ✔ | |
| 字串（string） | ⚠️ 有限支援 | 長度需固定或限制上限 |
| 陣列（定長） | ✔ | 編譯期固定大小 |
| 陣列（動長） | ⚠️ 有限支援 | 須使用 `rosidl_runtime_c__*` 型別 |
| 物件巢狀 | ✔ | 需先定義子訊息 |
範例：
可以在 micro-ROS 用這種定義：
```msg
float32[3] accel
```
但不能使用：
```msg
float32[] accel # 動態長度不保證支援
```
---
### 6. 自訂訊息型別的建立步驟
以「溫度 + 濕度」為例，建立一個新的 `EnvData.msg`。
#### (1) 建立目錄結構
```
my_msgs/
├── msg/
│ ├── EnvData.msg
├── package.xml
└── CMakeLists.txt
```
#### (2) 編寫 `EnvData.msg`
```msg
float32 temperature
float32 humidity
```
#### (3) 編輯 `CMakeLists.txt`
```cmake
find_package(rosidl_default_generators REQUIRED)
rosidl_generate_interfaces(${PROJECT_NAME}
"msg/EnvData.msg"
)
```
#### (4) 在 micro-ROS Client 專案中引用
在 C 程式碼裡：
```c
#include "my_msgs/msg/env_data.h"
my_msgs__msg__EnvData data;
data.temperature = 25.3;
data.humidity = 40.2;
rcl_publish(&publisher, &data, NULL);
```
---
### 7. 資料同步與版本一致性
micro-ROS Client 與 ROS 2 節點使用相同的 `.msg` 定義，
所以**兩邊必須用同一份編譯出的介面檔案**。
建議在同一個工作空間內管理：
```
src/
├── my_msgs/ # 自訂訊息
├── micro_ros_client/ # MCU 專案
└── ros2_host_node/ # 主機節點
```
Host 端與 Client 端在建構時都 include 來自 `my_msgs` 的頭檔，
確保結構完全一致。
---
### 8. IDL 與跨語言對應
ROS 2 的 `.msg` 實際上在底層轉換為 IDL（Interface Definition Language）。
這使得 ROS 能同時生成多語言綁定：
| ROS 2 型別 | C 對應 | Python 對應 |
| ------------ | -------------------------- | ------------- |
| `float32` | `float` | `float` |
| `int32` | `int32_t` | `int` |
| `string` | `rosidl_runtime_c__String` | `str` |
| `float32[3]` | `float data[3]` | `list[float]` |
在 micro-ROS 裡，使用的是 C 版本的封裝。
它會把每個欄位展開成純 C 結構，方便 MCU 操作。
範例（自動產生的 C 定義）：
```c
typedef struct my_msgs__msg__EnvData
{
float temperature;
float humidity;
} my_msgs__msg__EnvData;
```
---
### 9. 記憶體配置與訊息初始化
由於 MCU 沒有動態記憶體，
micro-ROS 的訊息必須在使用前明確初始化。
```c
my_msgs__msg__EnvData msg;
my_msgs__msg__EnvData__init(&msg);
msg.temperature = 26.5;
msg.humidity = 42.1;
rcl_publish(&pub, &msg, NULL);
my_msgs__msg__EnvData__fini(&msg);
```
若使用標準型別（如 `std_msgs/msg/String`），
則需使用 `rosidl_runtime_c__String__assign()` 來設定字串內容：
```c
std_msgs__msg__String str;
std_msgs__msg__String__init(&str);
rosidl_runtime_c__String__assign(&str.data, "Hello micro-ROS");
```
---
### 10. 訊息壓縮與效能考量
micro-ROS 為了減少封包負擔，
在序列化時會使用 eProsima Fast-CDR 的緊湊模式。
**最佳化原則：**
1. 儘量使用定長型別（float、int）。
2. 避免字串與可變長陣列。
3. 將結構控制在 256 bytes 以內。
這樣可確保傳輸速率與延遲穩定，
特別是在 UART 或低速網路上運作時。
---
### 11. micro-ROS 不支援的特殊結構
* **Dynamic Nested Types**：巢狀結構中若包含動態長度字串會導致錯誤。
* **Union / Variant**：IDL 支援但 micro-ROS 不實作。
* **Time / Duration**：需用 `builtin_interfaces/msg/Time` 替代。
若需要傳時間戳，正確寫法：
```msg
builtin_interfaces/Time stamp
float32 data
```
---
### 12. 例：整合自訂訊息的 Ping-Pong 系統
你可以把 Ping-Pong 範例改成使用自訂訊息：
```msg
string msg
int32 counter
```
Host Node：
```python
from my_msgs.msg import PingData
...
data = PingData()
data.msg = "ping"
data.counter = self.counter
self.publisher.publish(data)
```
micro-ROS Client：
```c
#include "my_msgs/msg/ping_data.h"
...
my_msgs__msg__PingData rx_msg;
my_msgs__msg__PingData__init(&rx_msg);
printf("Received: %s #%d\n", rx_msg.msg.data, rx_msg.counter);
```
兩邊都能自動解析結構，無需手動序列化。
---
### 13. 小結
1. ROS 2 與 micro-ROS 共享相同的訊息定義機制（IDL → 語言封裝）。
2. micro-ROS 僅支援靜態、定長、POD 型態。
3. 所有自訂 `.msg` 檔必須同時存在於主機與 MCU 專案中。
4. 編譯時會自動生成對應的 C 結構與序列化程式。
5. 透過這一機制，micro-ROS 能以極低負擔實現複雜資料交換。
---
## 六、系統整合與開發環境
### 1. 為什麼要「整合開發環境」
micro-ROS 的本質是 ROS 2 的延伸模組，
但它同時要跑在兩個完全不同的世界上：
* **主機端（Host）**：ROS 2 + Ubuntu + DDS
* **微控制器端（Client）**：FreeRTOS / Zephyr / Arduino
要讓兩邊合作順利，你需要建立一個能同時管理、編譯、測試的環境，
這就是「整合開發環境（Integrated Development Workspace）」的目的。
它能讓：
1. micro-ROS Client 與 ROS 2 Host 共用同一份 `.msg` 定義。
2. Host 端與 Client 端都能用 `colcon build` 一次建構。
3. Agent 可以自動在 Host 啟動，進行測試與模擬。
---
### 2. 系統整體結構
整個開發環境通常由三個主要部分構成：
```
+---------------------------------------------+
| ROS 2 主機端 (Host) |
|---------------------------------------------|
| OS: Ubuntu 22.04 |
| ROS 2: Humble Hawksbill |
| Tool: colcon,micro_ros_setup,micro-ros-agent|
|---------------------------------------------|
| 節點角色：Subscriber / Controller / Agent |
+---------------------------------------------+
⇅ UDP / UART / Serial
+---------------------------------------------+
| micro-ROS 客戶端 (MCU) |
|---------------------------------------------|
| OS: FreeRTOS / Zephyr / Arduino Core |
| Lib: micro-ROS rclc / rcl / XRCE-DDS |
|---------------------------------------------|
| 節點角色：Publisher / Sensor / MotorCtrl |
+---------------------------------------------+
```
兩邊透過 Agent 通訊，維持同步的 ROS 2 Topic 資料流。
---
### 3. ROS 2 版本與 micro-ROS 對應
ROS 2 每個發行版對應一個 micro-ROS 版本。
官方明確要求 **版本必須匹配**，否則訊息結構或 API 可能不相容。
| ROS 2 版本 | micro-ROS 對應版本 | Ubuntu 推薦版本 | 支援狀態 |
| ------------------- | -------------- | ------------- | ------- |
| Foxy Fitzroy | Foxy | 20.04 LTS | LTS（舊） |
| Galactic Geochelone | Galactic | 20.04 / 22.04 | 穩定 |
| Humble Hawksbill | Humble | 22.04 LTS | LTS（推薦） |
| Iron Irwini | Iron | 22.04 / 24.04 | 最新 |
| Jazzy Jalisco | Jazzy | 24.04 LTS | 開發中 |
實務上目前最穩定的是 **Humble + micro-ROS Humble**，
幾乎所有範例與教學都以這對版本為主。
---
### 4. 建立工作空間（Workspace）
在主機端（Ubuntu）建立 ROS 2 Workspace：
```bash
mkdir -p ~/micro_ros_ws/src
cd ~/micro_ros_ws
```
載入 ROS 2 環境：
```bash
source /opt/ros/humble/setup.bash
```
---
### 5. 安裝 micro-ROS 開發工具
micro-ROS 提供官方的 `micro_ros_setup` 套件，
可自動建立、交叉編譯、模擬 micro-ROS Client。
```bash
sudo apt install ros-humble-micro-ros-setup
```
---
### 6. 初始化 micro-ROS 專案
切換到工作目錄：
```bash
cd ~/micro_ros_ws
ros2 run micro_ros_setup create_firmware_ws.sh freertos esp32
```
這個指令會：
1. 建立 micro-ROS firmware 專案。
2. 自動下載對應的 FreeRTOS / ESP-IDF / micro-ROS libraries。
3. 建立 MCU 編譯環境。
---
### 7. 建構 micro-ROS Firmware
```bash
cd firmware
ros2 run micro_ros_setup build_firmware.sh
```
這一步會：
* 編譯 MCU 專案。
* 產生 micro-ROS 客戶端二進位檔（例如 `micro_ros_esp32.bin`）。
---
### 8. 主機端啟動 micro-ROS Agent
在 Host 端開新終端機，啟動 Agent：
```bash
source /opt/ros/humble/setup.bash
micro-ros-agent udp4 --port 8888 -v6
```
說明：
| 參數 | 功能 |
| ------------- | -------------- |
| `udp4` | 使用 IPv4 UDP 傳輸 |
| `--port 8888` | 指定通訊埠 |
| `-v6` | 顯示封包細節 |
若使用 UART：
```bash
micro-ros-agent serial --dev /dev/ttyUSB0 -b 115200
```
---
### 9. 檢查通訊狀態
啟動 Agent 後，你應該會看到：
```
[INFO] Micro XRCE-DDS Agent running...
[INFO] Client connected, ID: 0x01
```
這代表 MCU 已成功連線。
接著在另一個終端機：
```bash
ros2 topic list
```
若有 `/microROS/ping` 或 `/microROS/temp` 等 Topic 出現，就代表資料流已建立。
---
### 10. 整合自訂訊息與 Workspace 同步
若有自訂 `.msg` 型別（例如 `EnvData.msg`），
建議統一放在 Workspace 裡的 `my_msgs` 專案中：
```
micro_ros_ws/
├── src/
│ ├── my_msgs/
│ │ ├── msg/EnvData.msg
│ │ ├── CMakeLists.txt
│ │ └── package.xml
│ ├── micro_ros_firmware/
│ ├── host_controller/
```
然後在 MCU 端與 Host 端的 `CMakeLists.txt` 都加上：
```cmake
find_package(my_msgs REQUIRED)
ament_target_dependencies(target_name my_msgs)
```
這樣一旦重建 Workspace，
Host 與 Client 就會同時擁有相同的訊息結構。
---
### 11. FreeRTOS 與 micro-ROS 整合
micro-ROS Client 通常執行在 FreeRTOS 的任務中。
範例架構：
```c
void appMain(void *argument)
{
rclc_support_t support;
rclc_support_init(&support, 0, NULL, &allocator);
...
for(;;)
{
rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100));
vTaskDelay(pdMS_TO_TICKS(100));
}
}
```
這樣設計讓 micro-ROS 能與其他任務（例如感測器採樣、LED 控制）
在 RTOS 的 Task 排程中共存，保證即時性。
---
### 12. 在 Ubuntu 上模擬 micro-ROS Client
如果沒有 MCU，也可以直接在電腦上模擬：
```bash
ros2 run micro_ros_setup configure_firmware.sh host
ros2 run micro_ros_setup build_firmware.sh
ros2 run micro_ros_setup run_firmware.sh
```
此模式會用 C 節點模擬 micro-ROS Client，
可搭配 Agent 測試封包流動與功能正確性。
---
### 13. 常見環境錯誤與排除
| 問題 | 原因 | 解決方案 |
| ------------------------- | ---------------- | ------------------------ |
| `Agent connection failed` | MCU 未連線或 port 錯誤 | 檢查 `--port` 或 USB 裝置名稱 |
| `build_firmware.sh` 失敗 | 缺少 toolchain | 安裝 ESP-IDF 或 ARM GCC |
| Topic 收不到資料 | QoS 設定不符 | 在 Host 與 Client 使用相同 QoS |
| 訊息解析錯誤 | `.msg` 不一致 | 確保兩端使用同一套 `my_msgs` 套件 |
---
### 14. 多節點整合（Launch 範例）
在 ROS 2 端可以建立 `micro_ros_system.launch.py`，
同時啟動 Agent、控制節點與視覺化節點：
```python
from launch import LaunchDescription
from launch_ros.actions import Node
def generate_launch_description():
return LaunchDescription([
Node(package='micro_ros_agent', executable='micro_ros_agent', arguments=['udp4', '--port', '8888']),
Node(package='host_controller', executable='controller_node'),
Node(package='rqt_gui', executable='rqt_gui')
])
```
執行：
```bash
ros2 launch my_system micro_ros_system.launch.py
```
即可自動啟動整個 micro-ROS 網路。
---
### 15. 各版本函式庫對應與相容性
| 套件名稱 | ROS 2 對應 | 功能 |
| --------------------- | ---------------- | ----------- |
| `rclpy` | ROS 2 Host 端 | Python 節點開發 |
| `rclcpp` | ROS 2 Host 端 | C++ 節點開發 |
| `rclc` | micro-ROS Client | C 節點開發 |
| `micro_ros_agent` | ROS 2 Host 端 | Agent 程式 |
| `micro_ros_setup` | ROS 2 Host 端 | 自動建構與模擬工具 |
| `microxrcedds_client` | MCU 端 | 封包協定層 |
只要版本相符，這些套件會自動整合。
---
### 16. 環境維護與升級
建議每次建構前重新載入環境：
```bash
source /opt/ros/humble/setup.bash
colcon build --symlink-install
source install/setup.bash
```
micro-ROS 升級時也需重建 firmware：
```bash
ros2 run micro_ros_setup update_firmware.sh
```
這樣能避免 `rosidl` 與 `rclc` 不相容的問題。
---
### 17. 小結
* micro-ROS 的開發需要同時考慮主機與 MCU 端。
* 透過 Workspace 整合可共用訊息與編譯環境。
* `micro_ros_setup` 是最重要的建構工具。
* Host 與 Client 必須保持版本一致。
* 可使用 Ubuntu 模擬環境快速測試封包流。
整體開發流程如下：
```
撰寫程式（Host / MCU）
↓
共用訊息（.msg）
↓
colcon build（同步建構）
↓
啟動 micro-ROS Agent
↓
驗證資料流（ros2 topic echo）
```
---
## 七、實務應用場域（Practical Applications of micro-ROS）
### 1. 為什麼 micro-ROS 適合實務應用
micro-ROS 的定位，就是讓「感測與控制」的最底層設備能說 ROS 的語言。
在現代系統裡，大型主機處理決策（AI、導航、資料融合），
小型控制器負責即時任務（驅動馬達、讀感測器、傳遞資料）。
這兩層如果沒有共通通訊架構，就要手動設計 UART、I2C、MQTT 等協定。
micro-ROS 解決了這個痛點，它讓這些小裝置直接變成 ROS 節點。
---
### 一、IoT 與感測網（Internet of Things）
#### 1. 應用場景
智慧農業、智慧建築、環境監測、能源管理系統等，
通常有上百個感測節點（溫度、濕度、氣體、光照），
資料需要集中到主機再上傳雲端。
micro-ROS 可以讓每個感測器板都成為一個「ROS 2 節點」，
自動以 Topic 發布資料到主機，不必再做自訂通訊協定。
#### 2. 系統架構圖
```
+---------------------------+
| ROS 2 Host Node |
|---------------------------|
| Aggregator / Cloud Bridge |
| micro-ROS Agent (UDP) |
+-------------+-------------+
↑
Wi-Fi / Ethernet
↑
+-------------+-------------+
| micro-ROS Clients (MCUs) |
|---------------------------|
| Temp Node | /sensor/temp|
| Humid Node | /sensor/hum |
| Light Node | /sensor/lux |
+---------------------------+
```
#### 3. 資料流解釋
1. 每個 MCU 節點（如 ESP32）使用 micro-ROS 以 UDP 傳送感測資料：
`/sensor/temp`, `/sensor/hum`, `/sensor/lux`。
2. 主機上的 micro-ROS Agent 收到封包並轉成 DDS。
3. ROS 2 Host Node 聚合資料，並可直接以 Python 發布到雲端 API。
範例（主機端 Python 節點）：
```python
def callback(data):
publish_to_cloud(data.temperature, data.humidity)
```
#### 4. 優點
| 面向 | micro-ROS 帶來的優勢 |
| --- | ------------------------------- |
| 通訊 | 不需自訂協定，直接用 Topic 傳輸 |
| 整合 | 可直接接入 ROS 2 雲端橋接（如 MQTT Bridge） |
| 可擴展 | 新增感測器只需新增節點 |
| 成本 | MCU 價格低、功耗低、可長期運作 |
#### 5. 延伸應用
* 智慧電表（Energy metering）
* 冷鏈監控（Cold-chain monitoring）
* 城市噪音監測
* IoT 資料即時儀表板（整合 RViz / rqt）
---
### 二、機器人與自動化系統（Robotics）
#### 1. 應用場景
在機器人系統中，主機（Jetson、NUC）通常負責導航與 AI，
而下層控制板（STM32、ESP32）負責馬達與感測。
這種「主控＋子控制器」架構是 micro-ROS 的完美舞台。
#### 2. 系統架構圖
```
+----------------------------------+
| ROS 2 Host (AI) |
|----------------------------------|
| Navigation / Vision / Planning |
| micro-ROS Agent (serial) |
+---------------+------------------+
|
UART
|
+---------------+------------------+
| micro-ROS Client (MCU) |
|----------------------------------|
| Motor Controller / Encoder Node |
| Ultrasonic Sensor Node |
+----------------------------------+
```
#### 3. 資料流
1. Host Node 發布 `/cmd_vel`（速度命令）。
2. MCU 端的 micro-ROS Subscriber 收到命令 → 控制馬達 PWM。
3. MCU 端的 micro-ROS Publisher 發布 `/odom`（里程資訊）。
4. Host 端的 Navigation Node 根據 `/odom` 計算位置。
#### 4. 範例主機端 Python 節點
```python
from geometry_msgs.msg import Twist
def move_forward(pub):
msg = Twist()
msg.linear.x = 0.3
msg.angular.z = 0.0
pub.publish(msg)
```
micro-ROS 端（C 程式）：
```c
rcl_subscription_t sub;
rclc_subscription_init_default(&sub, &node,
ROSIDL_GET_MSG_TYPE_SUPPORT(geometry_msgs, msg, Twist),
"/cmd_vel");
```
這樣 MCU 就能直接理解 ROS 2 的控制訊息。
#### 5. 延伸應用
* ROS 2 自走車：主機負責 SLAM、MCU 控制驅動。
* 智慧機械臂：ROS 2 做運動規劃，micro-ROS 控制馬達伺服。
* 自動搬運車（AGV）：ROS 2 統籌路徑、micro-ROS 執行底層驅動。
---
### 三、工業控制與邊緣運算（Industrial / Edge Applications）
#### 1. 應用場景
在工業自動化中，感測器與控制器分散各地。
傳統做法是使用 Modbus、CAN、PROFINET。
但現在 ROS 2 被引入工控領域，
micro-ROS 讓現有的微控制器可以在不改硬體的情況下，
直接成為 ROS 節點參與資料交換。
#### 2. 系統結構
```
+---------------------------------+
| ROS 2 Host (Edge PC) |
|---------------------------------|
| Process Monitor Node |
| micro-ROS Agent (CAN/UDP) |
+---------------------------------+
↑
CAN Bus / Ethernet
↑
+---------------+---------------+
| micro-ROS Client (STM32) |
|-------------------------------|
| Pressure Sensor Node |
| Valve Controller Node |
+-------------------------------+
```
#### 3. 資料流
* 每個 micro-ROS 節點發佈感測資料：
`/sensor/pressure`, `/sensor/flowrate`。
* Host Node 訂閱後整合並作邏輯判斷，
若超出範圍，發送 `/cmd/valve` 回控制器節點。
#### 4. micro-ROS 在工控的優勢
| 面向 | 優勢 |
| ---- | --------------------- |
| 可靠性 | DDS 架構 + QoS 保證資料到達 |
| 可擴充性 | 新設備僅需掛上 Agent |
| 整合性 | 支援多介面（CAN, UART, UDP） |
| 即時性 | FreeRTOS 排程，毫秒級反應 |
#### 5. 實務應用案例
* 智慧工廠設備監控（機械壓力、溫度回饋）
* 電力變壓站數據收集與診斷
* 自動化流水線控制（以 micro-ROS 取代 PLC 分層）
---
### 四、教育與研究應用（Education & Research）
#### 1. micro-ROS 作為教學工具
因為 micro-ROS 可以在低成本硬體上執行（ESP32、Arduino Nano），
學校與研究單位廣泛使用它來教學「嵌入式 ROS」。
學生不需要昂貴的開發板，只要一台筆電與一片 ESP32，
就能在課堂上體驗從感測、封包、到 ROS 通訊的整個過程。
#### 2. 典型課程架構
| 單元 | 教學內容 | 實作成果 |
| ----- | ------------ | ---------------- |
| 第 1 週 | ROS 2 架構 | Hello World Node |
| 第 2 週 | micro-ROS 簡介 | Client 連線 Agent |
| 第 3 週 | Topic 通訊 | MCU 傳感測資料到 PC |
| 第 4 週 | Service 實作 | MCU 接收指令控制 LED |
| 第 5 週 | IoT 延伸 | 資料上傳雲端平台 |
| 第 6 週 | 整合專題 | 完成感測 + 控制專案 |
#### 3. 實驗室常見專題
* **導盲車（GuideBot）**：micro-ROS 控制距離感測與避障；ROS 2 主機進行語音辨識與路徑規劃。
* **智慧農場模擬系統**：多個 micro-ROS Client 模擬溫濕度感測；ROS 2 聚合資料後顯示即時趨勢圖。
* **IoT Security 專題**：研究 micro-ROS Agent 資料驗證與加密。
#### 4. 教育應用的價值
* 讓學生同時學習 **嵌入式程式設計 + ROS 架構思維**。
* 實際理解分散式系統、封包通訊與即時控制。
* micro-ROS 是 ROS 2 教學鏈的「前哨站」，
幫助學習者從基礎的 Node 邏輯跨入系統整合思維。
---
### 五、micro-ROS 的跨領域價值
micro-ROS 不只屬於機器人領域。
它的輕量特性讓它成為 **IoT、AIoT、邊緣運算** 的核心通訊層。
| 領域 | 應用 | 角色 |
| -------- | ----------- | ---- |
| IoT | 感測器網路、智慧城市 | 邊緣節點 |
| Robotics | 自走車、機械手臂 | 驅動控制 |
| 工控 | 智慧工廠、遠端監控 | 即時感測 |
| 教育 | 嵌入式與 ROS 教學 | 實驗平台 |
在這些場合，micro-ROS 讓「感測端」、「控制端」、「決策端」
可以統一在一個 ROS 2 通訊生態裡運作。
---
### 6. 小結
1. micro-ROS 已從單純的嵌入式通訊框架，成為 **ROS 2 的邊緣延伸層**。
2. 在 IoT、機器人與工控場域中，它負責「即時、低功耗、標準化」的資料傳輸。
3. 它使開發者能用一套 ROS 工具鏈貫穿從 AI 到硬體的整個開發流程。
4. 它在教育與研究上的普及，正讓 ROS 走入嵌入式與物聯網時代。
---
## 八、理論篇總結（Summary of the micro-ROS Theoretical Series）
### 1. micro-ROS 為何誕生
micro-ROS 並不是 ROS 2 的替代品，而是 ROS 2 的「邊緣延伸層」。
ROS 2 專注於高階作業系統與強大運算平台（例如 Jetson、x86、雲端伺服器），
但現實世界的大多數設備是微控制器（MCU），
記憶體僅數百 KB，卻是系統的感測與控制基礎。
micro-ROS 讓這些 MCU 也能以 **ROS 的語言** 參與系統，
透過輕量化協定 Micro XRCE-DDS 與 Agent 橋接，
實現「從感測器到雲端」的完整通訊閉環。
---
### 2. 架構重點回顧
micro-ROS 的三層結構：
```
ROS 2 Node ←DDS→ micro-ROS Agent ←XRCE-DDS→ micro-ROS Client
```
| 組件 | 執行環境 | 功能 |
| -------------------- | --------------------- | --------- |
| **ROS 2 Node** | Ubuntu / Jetson / x86 | 資料處理與決策 |
| **micro-ROS Agent** | Host (Ubuntu) | 封包轉譯、連線管理 |
| **micro-ROS Client** | MCU / FreeRTOS | 感測與控制節點 |
這個設計確保了高效能（Host）與即時性（MCU）可以共存，
兩邊透過 Agent 交換封包而不需改協定。
---
### 3. 通訊與封包哲學
micro-ROS 採用的 **Micro XRCE-DDS** 是 DDS 的極簡版本：
* 用 Client–Agent 模式取代節點間直連。
* 用固定大小封包（50–150 bytes）降低傳輸負擔。
* 用靜態記憶體配置確保即時性。
Agent 的角色相當於「翻譯官」，
讓不同層級的裝置都能參與相同 DDS 網路。
---
### 4. 與 ROS 2 的關係
| 面向 | ROS 2 | micro-ROS |
| ---- | --------------- | --------------------------- |
| 功能範圍 | 完整生態（AI、導航、服務） | 嵌入式通訊與控制 |
| 通訊協定 | DDS | Micro XRCE-DDS |
| 語言支援 | Python / C++ | C / C++ |
| 作業系統 | Linux / Windows | FreeRTOS / Zephyr / Arduino |
| 封包方向 | 節點對節點 | Client–Agent |
| 資源需求 | 高 | 低 |
micro-ROS 專注於「即時與節能」，
讓 ROS 架構能延伸到每一顆感測器與執行器。
---
### 5. 訊息型別與資料一致性
* ROS 2 與 micro-ROS 共用 `.msg` / `.idl` 機制。
* 所有訊息在編譯階段轉成固定的 C 結構。
* micro-ROS 僅支援定長與靜態資料型別（避免動態記憶體）。
* 主機與 MCU 必須使用相同版本的訊息定義。
這種靜態資料交換方式，是 micro-ROS 能在 100KB RAM 環境下穩定運作的關鍵。
---
### 6. 系統整合流程
建立一個完整 micro-ROS 系統的步驟：
1. 在 Ubuntu 建立 ROS 2 + micro-ROS Workspace。
2. 使用 `micro_ros_setup` 產生 MCU 專案與工具鏈。
3. 建構 Firmware 並燒錄至 MCU。
4. 啟動 micro-ROS Agent（UDP / Serial）。
5. 用 `ros2 topic echo` 驗證通訊。
6. 整合自訂訊息、QoS 與多節點架構。
這套流程可同時支援開發、模擬與實體硬體部署。
---
### 7. 實務應用總覽
| 領域 | micro-ROS 的角色 |
| ----------- | -------------------- |
| **IoT 感測網** | 邊緣節點，負責資料收集與傳輸 |
| **智慧機器人** | 馬達控制、里程回報、避障偵測 |
| **工業控制** | 即時監測、閥門控制、機械狀態分析 |
| **教育研究** | 嵌入式 ROS 教學、封包模擬、網路實驗 |
在這些系統裡，micro-ROS 讓「硬體端」與「軟體端」以同樣的 ROS 語言協作。
---
### 8. 技術演進與未來方向
* **QoS 擴充**：逐步支援更多 DDS 參數（例如可靠性重傳）。
* **安全通訊**：整合 DDS Security Plugin，提供資料加密與認證。
* **跨語言支援**：未來可能透過 MicroPython 或 Cython Bridge 實驗性加入 Python 綁定。
* **AI at the Edge**：結合微型 AI 模型（如 TinyML）於 micro-ROS 節點上運行。
這些發展代表 micro-ROS 將成為「低功耗 AI 裝置」與「分散式 ROS 系統」的橋樑。
---
### 9. 全篇總結
micro-ROS 的價值在於「連結」。
> 它把嵌入式裝置與雲端計算之間的鴻溝，
> 用 ROS 架構的共同語言縫合起來。
學會 micro-ROS，代表你能掌握：
* ROS 架構的內部機制（Node、Topic、DDS）。
* 嵌入式系統的限制與優化思維。
* 分散式系統的通訊模式與整合技術。
最終目標不只是讓 MCU 發送資料，
而是建立一個 **統一、可擴展、即時反應的智慧系統**。
---
### 10. 延伸閱讀與參考
* [Official micro-ROS Documentation](https://micro.ros.org/docs/)
* [ROS 2 Humble API Reference](https://docs.ros.org/en/humble/)
* [eProsima Micro XRCE-DDS Specification](https://github.com/eProsima/Micro-XRCE-DDS)
* [rclc API Reference (C)](https://github.com/ros2/rclc)
* [micro-ROS Tutorials (Official GitHub)](https://github.com/micro-ROS/micro-ROS-demos)
---
### 11. 結語
micro-ROS 不是一項「小技術」，
而是一座讓嵌入式世界進入 ROS 宇宙的橋梁。
它讓感測器不再只是資料來源，而是分散式網路中的「智慧節點」。
這也是現代嵌入式工程與機器人學融合的象徵。
> 從微控制器到雲端，每一層都說 ROS 的語言。
---
Sign in with Wallet
Connect another wallet