本專案為國立成功大學114-1「數位電路導論」課程期末專題第一名作品。 透過整合 ROS 2 框架與 ESP32 微控制器，實現 12 自由度（12-DOF）六足機器人的低延遲步態控制與即時運動學解算，展現軟硬體協同設計 (Hardware-Software Co-design) 之系統架構能力。
點擊 GIF 即可跳轉至 YouTube 觀看完整展示影片：
本專案採用軟硬體解耦的設計思維，將上層的演算法邏輯與底層的硬體驅動分離，以確保系統的高擴充性與穩定度。
[ Upper Level: ROS 2 / PC ]
├── 🧠 Gait Controller (run_publisher_final.py)
│ ├── Multi-threading Keyboard Listener (異步指令接收)
│ └── Tripod Gait Generator (三角步態軌跡計算)
│
└── 📡 Bus Servo Driver Node (依賴庫整合)
└── Translates JointTrajectory to Serial Packets
[ Lower Level: Hardware / ESP32 ]
├── 🔌 ESP32 Microcontroller (Firmware: Serial Parsing & PWM)
└── ⚙️ 12 x Hiwonder Serial Bus Servos
為了達成高精度的步態控制與穩定的系統供電，本專案在硬體選型與佈線上經過嚴格評估，實現動力電源與邏輯電源的穩定分配。
| Component (零件名稱) | Specification / Model (規格型號) | Purpose in System (系統用途) |
|---|---|---|
| Microcontroller | Bus Servo Driver HAT (A) with ESP32-WROOM-32E | 擔任底層核心硬體，負責解析 ROS 2 傳來的串列封包，並生成對應的控制訊號。利用其雙核心與高時脈優勢處理即時控制。 |
| Actuators | Hiwonder Serial Bus Servos (45kg.cm High Torque) x 12 | 提供 12 自由度的關節動力。採用串列匯流排馬達而非傳統 PWM 馬達，大幅減少配線複雜度，並支援角度回讀功能。 |
| Power Supply | 12V / 10A AC/DC Adapter | 為 12 顆高扭力伺服馬達提供瞬間大電流，確保多軸連動時不會因壓降而導致控制器重啟。 |
| Structure | Custom Hexapod Frame | 六足機器人實體機構支撐，確保多軸連動時的結構剛性與幾何對稱性。 |
上位機的運算核心為 src/run_publisher_final.py，負責六足機器人的步態生成與指令發布。主要設計包含：
-
非同步多執行緒設計 (Multi-threading with Locks) 導入
threading.Thread與threading.Lock()，將「鍵盤指令監聽」與「步態運動主循環」分離。確保在進行三角步態（Tripod Gait）計算與發布時，系統仍能零延遲地響應使用者的中斷或轉向指令。 -
ROS 2 Trajectory Publishing 將計算出的各關節角度，封裝成標準的
JointTrajectory訊息格式，發布週期為 250ms。這個數值是實測夾出來的：週期過短時系統會當機，過長則步態速度不足，250ms 是兩個邊界之間能穩定運行的值。當機的原因推測為上位機的發布速率超過下游序列鏈路（driver node → 序列埠 → ESP32 → 12 顆匯流排馬達）的處理能力，未被消化的指令在佇列中持續累積所致。當時並未進一步驗證瓶頸是落在序列埠頻寬，或是每顆馬達逐一寫入的往返延遲——兩者對應的解法並不相同。以此專案的規模回頭看，較正確的做法應是在 ROS 2 的 QoS 層級設定有界佇列與適當的可靠性策略（步態指令屬於「僅最新值有意義」的資料），而非以人工試出一個發布週期來迴避問題。
-
三角步態實作 (Tripod Gait) 將 6 條腿分為兩組（Tripod 1 & Tripod 2），透過狀態機邏輯實現前進、後退與原地轉向，並保留
LIFT_OFFSET與PAN_OFFSET的參數化設計，方便後續調整。
我在本專案擔任 專案組長與系統整合 (Project Lead & System Integrator)，負責統籌六人團隊的分工與進度、建置主機端的 ROS 2 環境與 workspace 編譯、參與機構組裝，並執行從「程式跑得起來」到「機器人真的會走」之間的全機整合與除錯。
比起功能清單，這個專案真正教會我的東西寫在下面。開發期間我們累計損毀 3 顆伺服馬達與 2 片控制板，以下是各次失效的原因判定與後續處置：
初期未在馬達端設定關節的角度限制，步態指令將關節推向超出機構容許的位置。馬達抵住機構極限後無法到位，持續以最大扭力堵轉 (stall)，電流迅速攀升並冒煙。
處置： 在馬達設定與上位機指令兩端同時加上角度限制。軟體端的限制不能取代硬體端的限制——只要有任何一個指令來源繞過軟體檢查，馬達仍會撞到底。
上位機以過高的頻率發布關節指令，馬達持續高頻作動，產生的熱量超過散熱速率而燒毀。
這次失效最值得記錄的一點是：我們事前已經啟用了原廠軟體的溫度保護功能，但它沒有攔下這次損壞。 保護機制的觸發速度跟不上實際的熱累積速率，因此無法作為唯一的防線。此後我們改以控制發布週期從源頭限制作動頻率，而非依賴事後的保護機制。
一顆馬達自始就完全無法作動，但仍持續接收指令並發熱，最終燒毀。排查後確認為出廠即存在的瑕疵，與控制端無關。
這次的教訓是排查順序： 症狀（馬達不動）與軟體 bug 的表現一模一樣，我們一開始往程式的方向找。面對「不會動」的關節，應先以單顆馬達的獨立測試排除硬體不良，再回頭檢查控制邏輯，否則會在錯誤的方向上耗掉大量時間，而故障品在這段期間仍在持續受熱。
組裝過程中一顆螺絲掉落至通電的控制板上，跨接電路造成短路，板子當場冒煙報廢。
處置： 之後只要在板子上方進行任何作業，一律先鋪一層塑膠保護膜，讓掉落的金屬件落在膜上而非電路上。同時自備電動螺絲起子以減少手動作業時的失手機率。採用此措施後，未再因相同原因損失任何一片控制板。
本專案的成功運作，建立在以下優秀的開源驅動與工具庫之上。感謝以下 Repository 提供底層的通訊與校正支援：
- zlink-bus-servo-driver 作為 ROS 2 與匯流排馬達之間的通訊橋樑，負責處理底層的封包轉換與序列埠發送。
- ESP32_servo_control 燒錄於 ESP32 的韌體核心，負責接收上位機指令並輸出高精度的 PWM 訊號至 12 顆伺服馬達。
- tools 用於機器人組裝初期的零點校正與環境變數建置。
請確保已安裝 ROS 2 (Humble/Foxy) 並編譯上述依賴庫的工作區 (Workspace)。
# 啟動底層通訊節點 (依賴庫)
ros2 launch zlink_bus_servo_driver bus_servo_driver.launch.py
# 啟動本專案之步態控制大腦
python3 src/run_publisher_final.pyW: 前進 (Walk Forward)S: 後退 (Walk Backward)A: 原地左轉 (Turn Left)D: 原地右轉 (Turn Right)[Space]: 停止並回到站立姿態 (Stand)Q: 安全退出程式 (Quit)
本專案為 6 人團隊協作成果，感謝所有成員的專業分工與投入，讓這個六足機器人得以從理論走向實體。以下為團隊成員與職責劃分：
- [謝〇祐] (@RogerH0711) - Project Lead & System Integrator (專案組長與系統整合)
- 統籌六人團隊分工、開發進度與系統架構規劃。
- 建置主機端 ROS 2 開發環境與 workspace 編譯，參與機構組裝。
- 負責上位機操作與全機軟硬體之最終系統整合、失效分析與防護措施導入。
- [蔡〇森] (@Andy5533) , [廖〇嘉] (@PatrickLoveCode) - Algorithm & Software Engineers (演算法與軟體開發)
- 規劃底層程式碼架構。
- 負責步態控制程式 (
run_publisher_final.py) 的規格制定與實作，包含馬達配置與關節相對位置的定義、非同步多執行緒與中斷控制邏輯，以及後續除錯。
- [陳〇融], [顏〇勳] - Hardware & Mechanical Engineers (硬體與機構工程)
- 負責六足機器人實體機構組裝與伺服馬達走線設計。
- 規劃 ESP32 控制板電源分配與硬體線路連接。
- [黃〇銓] - QA & Field Testing (測試與調校)
- 執行伺服馬達零點硬體校正。
- 負責步態參數調優與實際場域運行之壓力測試。