機械手臂路徑規劃 2026｜MoveIt、RRT 與上線驗收流程

機械手臂路徑規劃不只選 RRT。從模型、碰撞場景、Path 與 Trajectory、時間參數化、控制器容差到實機驗收，建立可重複的 MoveIt 工程流程。

I Indexia Editorial Team · 2026年3月5日 · 約 21 分鐘 · 更新於 2026年8月8日

機械手臂路徑規劃不是「選 RRT 還是 A*」就結束。規劃器可能在幾何模型裡找到無碰撞路徑，實機仍可能因模型誤差、治具位姿、關節極限、時間參數化、控制器容差或安全系統而停止。

真正可上線的流程至少要連續通過六層：任務定義、機器人模型、Planning Scene、規劃器、Trajectory 與控制器、產線安全驗收。先把這六層分開，才能知道失敗是「沒有路」、「路不夠好」，還是「控制器無法按預期執行」。

本文依 2026 年 8 月 8 日可查閱的 MoveIt、OMPL、ROS 2、NVIDIA 與 ISO 官方資料整理。內容是工程規劃與驗收方法，不代替機器人製造商、系統整合商或職業安全專業人員的風險評估與安全驗證。

先分清 Path、Trajectory 與 Execution

層級	回答的問題	典型輸出	常見誤判
Path	從起點到終點有哪些幾何構型可走？	一串關節或笛卡兒空間狀態	找到路就等於能直接下給馬達
Trajectory	每個狀態在什麼時間到達？	位置、時間，以及可選的速度與加速度	路徑平滑就一定符合關節限制
Execution	控制器與實機能否跟上？	回授、誤差、容差、成功或中止	模擬成功就代表產線安全

MoveIt 的 motion planning 文件明確指出，規劃器通常先產生沒有時間資訊的 kinematic path，再由 adapter 加入速度與加速度限制，形成 time-parameterized trajectory。ROS 2 的 Joint Trajectory Controller 則依時間點嘗試追蹤軌跡，並可用 path tolerance 與 goal tolerance 判斷是否中止。

因此，看到 RViz 裡的綠色路徑只能證明規劃層成功，不能單獨證明控制器、驅動器、治具、工件與安全回路都能通過。

六層規劃卡：先把問題寫完整

在調參前先填這張表。任何一格沒有版本或證據，都可能讓 benchmark 失去可比較性。

層級	必填內容	合格證據
1. 任務	起點、目標、工具姿態、允許區域、禁止區域、節拍目標	可重播的 request 或任務檔
2. 模型	URDF/SRDF、關節限制、tool0/TCP、碰撞幾何	版本號、校正紀錄、模型可視化
3. 場景	治具、工件、箱體、附著物、允許碰撞矩陣	Planning Scene 快照與座標來源
4. 規劃	pipeline、planner ID、timeout、attempts、seed	完整參數檔與執行紀錄
5. 軌跡	時間參數化、速度／加速度縮放、最小間隙	Trajectory 與限制檢查結果
6. 執行	控制器、容差、speed scaling、回授與停止條件	模擬、低速試車、實機 log 與簽核

這也是台灣中小型工廠導入時最省溝通成本的文件。機器人原廠、視覺廠商、治具商與系統整合商若各自只交一段設定，問題發生時很難確認責任邊界；六層卡能把版本和輸入固定下來。

第一步：任務空間不是只有起點與終點

同一個末端目標姿態，六軸或七軸手臂可能有多組逆運動學解；不同解會經過完全不同的關節構型。任務定義至少要回答：

工具中心點 TCP 在哪裡，工具與負載何時更換。
末端姿態是固定、允許某軸旋轉，還是只要求位置。
搬運物是否要保持直立，線材或氣管是否限制腕部旋轉。
接近與離開段是否必須沿直線。
哪些區域可穿越，哪些區域即使不碰撞也不希望進入。
動態人員或工件是否會進入工作空間。

規劃器若只收到位置目標，可能選到數學上可達、現場卻不希望的肘部姿態。反之，把姿態、路徑限制與允許區域鎖得過緊，也可能讓可行空間縮到難以取樣。先把必要限制與偏好分開，才知道該放寬哪一項。

第二步：模型誤差會吃掉碰撞間隙

Planning Scene 的碰撞檢查依賴機器人與環境模型。常見失敗並不是演算法太差，而是模型沒有代表現場：

URDF 的 link collision mesh 過度簡化或過度精細。
SRDF 的 self-collision matrix 沿用舊工具。
TCP、法蘭、夾爪與相機外參沒有同步更新。
工件夾起後沒有設為 attached collision object。
治具、棧板或護欄座標來自不同 frame。
CAD 是名目尺寸，現場線材、螺栓與公差未納入。

碰撞模型不必把每顆螺絲畫滿，但必須保守涵蓋會影響動作的外形。對狹窄通道，應明列模型膨脹或安全間隙的來源與限制；不要把編輯者自行設定的固定毫米數寫成通用安全標準。

第三步：演算法不是排行榜，要看問題型態

MoveIt 可透過 planning pipeline 使用不同規劃器。預設常見的 OMPL 是抽樣式規劃庫；MoveIt 也提供 CHOMP、Pilz 等 pipeline。選擇時先看任務，而非只比較一次規劃時間。

方法	適合先嘗試的情境	優點	需要留意
RRT-Connect	單次、自由空間、先找可行解	常用來快速尋找連通路徑	路徑品質受 seed 與場景影響
RRT* / Informed RRT*	願意用較多時間改善成本	可持續尋找更佳解	有限 timeout 下不保證已收斂
PRM / PRM*	同一場景大量不同起終點查詢	可重用 roadmap 的多查詢思路	場景頻繁變動時重用價值下降
CHOMP / STOMP 類最佳化	已有可行種子、想改善平滑或間隙	可用成本函數調整軌跡	可能受初始解與局部最小值影響
Pilz PTP / LIN / CIRC	工業流程需要明確點到點、直線或圓弧段	運動語意清楚	每段仍須符合機器人、場景與限制
cuMotion 最佳化	NVIDIA 生態中的碰撞感知軌跡生成	同時考量平滑、避障與目標成本	需依官方支援硬體、版本與模型驗證

OMPL 官方將 RRT*、PRM* 等列為漸近最佳規劃器，但這不代表每次短 timeout 都會得到全域最佳路徑。正式比較時應固定問題、重複不同 seed，觀察分布，而不是拿一次最快結果下結論。

A* 與 Dijkstra 為何不能直接和 RRT 排名？

A* 與 Dijkstra 常用於已離散化的圖或格點；機械手臂的關節空間維度高，如何離散化、如何產生鄰接與碰撞檢查，會決定計算量與答案。RRT、PRM 等則直接在連續狀態空間取樣。兩類方法都能成為系統的一部分，但不能只用演算法名稱推定哪一個「最適合機械手臂」。

第四步：Planning Scene 要能重播

規劃測試若只保存成功路徑，之後無法重現。每個失敗案例至少保存：

起始 joint state 與時間戳。
目標 pose、frame 與容差。
機器人模型與工具版本。
所有 collision object、attached object 與 allowed collision matrix。
planner ID、timeout、attempts、seed 與縮放參數。
成功／失敗碼、規劃時間與產生的 trajectory。

若場景來自相機或深度感測器，還要保存感測器座標、更新延遲、遮蔽與物件生命週期。動態障礙避讓不是把靜態碰撞物定期更新就自然成立；感知、預測、重規劃頻率與停止策略必須一起設計。

第五步：用可重複 benchmark 選規劃器

MoveIt 提供 benchmark 工具，用相同 query、場景與參數比較 planner。建議把產線代表情境分成至少四組：空場、正常治具、最窄通道、接近關節極限。每組都使用多個固定 seed 重複，並保留失敗樣本。

指標	回答的問題	不應如何解讀
成功率	在限定時間內找到解的穩定度	不代表實機執行成功率
規劃時間分布	一般與最慢案例要等多久	不只看平均值或單次最快值
路徑長度	關節或末端移動成本	最短不等於最平滑或最安全
最小碰撞間隙	模型裡離障礙多近	不等於現場法規安全距離
關節極限餘裕	是否貼近位置限制	尚須看速度、加速度與控制器
軌跡時間	時間參數化後的理論節拍	不含 PLC、夾具、感測與等待
執行誤差	控制器能否追蹤	必須在實機低速、受控條件驗證

不要在看到一條漂亮路徑後就調高速度。先找出會失敗的 request，確認是無解、timeout、起點碰撞、限制矛盾或控制器拒絕，再決定調模型、場景、規劃器或時間參數化。

第六步：時間參數化與控制器容差

幾何路徑要加入每個 waypoint 的時間，才能交給控制器。速度與加速度限制應來自機器人與應用設定；工具、負載、姿態和製程也可能要求更保守的縮放。

ROS 2 Joint Trajectory Controller 可接收位置，以及依介面組合接收速度、加速度或 effort；FollowJointTrajectory action 能設定 path 與 goal tolerance。若執行誤差超過容差，控制器可中止軌跡並保持當前位置。

常見症狀與層級如下：

症狀	先查哪一層	可能原因
規劃成功但控制器拒絕	Trajectory / controller	joint 名稱、時間、介面或容差不符
模擬順、實機頻繁降速	execution	原廠 speed scaling、安全功能或負載限制
狹窄處抖動或繞遠	model / planning	間隙、碰撞幾何、seed、成本或限制
起點立刻報碰撞	model / scene	校正、attached object、frame 或 self-collision
終點可達但姿態翻轉	task / IK	目標容差太寬、解支路或 joint seed 不合
靜態測試成功、來料後失敗	scene / perception	工件位姿、遮蔽、更新延遲或版本不同

若使用 speed scaling，還要確認控制器與硬體各自在哪一層縮放。ROS 2 控制器文件指出，不正確處理硬體端速度縮放可能造成路徑誤差累積；因此 log 應同時保留 desired、actual 與 scaling state。

笛卡兒直線不等於關節動作容易

點膠、焊接、打磨與插入常要求 TCP 沿直線或曲面移動。末端路徑在笛卡兒空間看似簡單，映射到關節空間後可能接近奇異點、關節極限或產生速度放大。

上線前至少檢查：

Cartesian path 的完成比例是否達到任務要求。
每段逆運動學是否落在同一可接受解支路。
關節速度、加速度與 jerk 是否符合控制器及製程。
工具姿態、法向量與製程速度是否連續。
接近奇異點時是否有可預期的降速、改姿態或停止策略。

只做 waypoint 插值而不做碰撞檢查、時間參數化與控制器驗證，不能視為完整軌跡規劃。

模擬到實機的四道閘門

閘門一：離線可重播

固定模型、場景、request 與 seed，確認相同軟體版本能重現結果；失敗案例也要能重播。

閘門二：模擬控制器

不要只播放 RViz 動畫。把 trajectory 送入與實機介面一致的模擬控制器，檢查 joint 名稱、時間、容差、preemption 與回授。

閘門三：實機低速、空載與受控區域

由合格人員在依現場程序建立的受控條件下，先做低速、空載與單段動作；再依風險評估逐步加入工具、工件與完整節拍。不要把「低速」本身當成安全認證。

閘門四：產線異常與復歸

測試急停後狀態、保護停止、斷電、工件缺失、感測器延遲、規劃 timeout、控制器中止與人工復歸。成功跑完一次正常循環，不代表異常流程可管理。

ISO 10218-1:2025 著重工業機器人本體安全，ISO 10218-2:2025 則涵蓋工業機器人應用與系統整合。規劃器的 collision-free 結果不是風險評估、保護裝置、停止距離或整合驗證的替代品。

台灣產線導入的版本交付表

多供應商專案常見問題不是沒有演算法，而是「模擬那版」與「現場這版」不同。每次交付至少列出：

項目	交付內容	變更後必測
機器人	型號、控制器、韌體、負載資料	joint limits、控制器介面、縮放
工具	TCP、重量、重心、碰撞模型	自碰撞、狹窄路徑、制動與節拍
治具	CAD 版次、實測偏差、frame	最小間隙與最窄通道
感知	相機、外參、延遲、更新規則	遮蔽、遺失物件、過期資料
軟體	ROS 2、MoveIt、planner、參數	benchmark 與失敗案例重播
PLC / 安全	握手、模式、停止與復歸	timeout、急停、保護停止、重啟