UBTECH GHRC 2026基準流程是一套官方參考流程：啟動Walker S2模擬器，以鍵盤遠端操作收集四路攝影機畫面與關節資料，存成LeRobotDataset v3，再訓練、評估ACT或π0策略。較穩妥的順序是先讓Isaac Sim 5.1.0容器與GPU驅動程式相容，用官方資料完整重現一次，再加入自有資料。這套流程把實體 AI（Physical AI）的模擬、資料與策略接成一條可稽核管線；一開始就跑大型訓練，反而難以區分環境與資料錯誤。
先界定官方基準流程真正涵蓋的範圍
GHRC 2026官方技術文件提供從物理模擬、資料收集、模型訓練到策略部署的整合流程。Walker S2環境的狀態空間包括14個手臂關節、4個夾爪關節與2個夾爪控制命令，共20維；攝影機則是頭部左右與手腕左右四路RGB影像。
官方資產與訓練資料另放在Hugging Face，使用者從程式碼儲存庫取得子模組與資料集。基準流程的功能是讓參賽者站在同一起點，並非完整複製實機Walker S2所有感測、安全控制與動力學的數位分身。虛擬環境高分之後，仍要處理Sim-to-Real驗證。
| 元件 | 官方基準流程中的角色 | 第一次執行先查什麼 |
|---|---|---|
| Isaac Sim | 提供Walker S2物理環境與感測渲染 | 容器版本、GPU辨識、即時係數 |
| 鍵盤遠端操作 | 產生工作示範與紀錄段落 | 輸入設備路徑、控制延遲、中止鍵 |
| LeRobotDataset v3 | 保存影像、狀態、動作與中繼資料 | 攝影機順序、fps、紀錄成功標籤 |
| ACT | 預測動作區塊的模仿學習基準 | 區塊長度、觀測視窗、記憶體使用量 |
| π0 | 處理影像、語言與動作的策略基準 | 檢查點、前處理、工作文字一致性 |
安裝最常卡在驅動程式與容器組合
官方文件列出的最低配置為CPU 4核心、RAM 32GB、SSD 50GB、GeForce RTX 4080、VRAM 16GB；建議配置是8核心、RAM 64GB、SSD 500GB、RTX 5080；理想配置則為16核心、RAM 64GB、1TB NVMe、RTX PRO 6000 Blackwell 48GB。若同時訓練模型，儲存容量與VRAM都要保留餘裕。
支援OS表格列出Ubuntu 22.04/24.04與Windows 10/11，但Docker命令和鍵盤設備範例主要以Linux呈現。基礎映像檔為`nvcr.io/nvidia/isaac-sim:5.1.0`，CUDA版本是12.8。文件建議使用580系列驅動，並警告安裝595時，容器內Isaac Sim可能在稍後當機；版本較新不代表一定相容。
建置前分別檢查`nvidia-smi`、Docker能否存取GPU、NVIDIA Container Toolkit與剩餘容量。接著先用官方映像檔開空場景，最後才載入GHRC資產。若一次安裝所有相依項目，很難判斷黑畫面、渲染器當機或資產缺漏是哪一層造成。NVIDIA Isaac Sim官方文件的版本已知問題也應和GHRC固定版交叉比對。
第一次執行先對齊四路影像與20維狀態時間
畫面出現Walker S2、按鍵也有反應，不代表資料管線正常。頭部左右、手腕左右影像要以正確名稱與順序保存；關節狀態和命令需共用同一時間戳軸，畫面遺失時也要留下中繼資料。若左右攝影機對調，訓練仍可能前進，模型卻會學錯手與物件的關係。
遠端操作在Linux的`/dev/input/event*`尋找鍵盤。沒有把設備掛載到Docker時，主機雖看得到輸入，模擬器仍收不到。自動偵測若指向多個設備，可改用`/dev/input/by-id/`穩定連結，也能降低容器重啟後event編號改變的問題。
.jpg){kind=link}
LeRobotDataset v3 的重點是紀錄定義，不只是資料夾
LeRobotDataset v3以共同格式保存與讀取不同機器人的影像、狀態及動作。Hugging Face LeRobot官方文件把資料工具、機器介面與訓練策略放在同一生態。GHRC採用這套結構後，公開資料與自有紀錄可使用相同工具處理。
但檔案能開啟，不等於資料品質合格。起始狀態、工作文字、成敗標準、操作者介入、攝影機fps與關節週期都要固定。`Part_Sorting`、`Conveyor_Sorting`、`Foam_Inlaying`、`Packing_Box`名稱不同時，物件與結束條件也要分開。若默默刪除失敗嘗試，既學不到復原，也會扭曲評估分母。
| 資料QA項目 | 合格條件範例 | 有問題時會發生什麼 |
|---|---|---|
| 攝影機對應 | head_left/right、wrist_left/right與樣本一致 | 左右手對到錯誤影像 |
| 時間同步 | 接觸時的影像、狀態、動作落差在容許範圍 | 抓取前就留下力命令 |
| 起始狀態 | 記錄物件與機器位置分布、重置規則 | 只在特定配置成功 |
| 工作文字 | 同一工作使用相同意義與名稱 | π0把文字差異判成另一工作 |
| 切分 | 依場景與物件分離訓練、評估 | 驗證高分，新配置卻失敗 |
| 失敗保存 | 保留中止理由與最後有效畫面 | 無法計算失敗率與復原能力 |
ACT 適合先驗證流程，π0 對輸入條件要求更廣
ACT預測短動作區塊，把長操作穩定串起來。它的輸入輸出較明確，適合先當資料管線的基準。可先用官方檢查點與資料重現訓練、推論，再刻意移除少量資料或遮住攝影機，觀察敏感度。
π0類策略把影像、自然語言工作指示與機器人狀態一起處理，方向更通用，但文字前處理、檢查點相容性、記憶體需求與動作表示都要一致。名稱更新不代表一定勝過ACT，應用相同評估紀錄和成功定義比較。機器人基礎模型可補充概念。
比較兩者時，不能只看訓練損失與平均成功率。應分列物件別失敗、長工作累積誤差、攝影機遮蔽、起始位置變化，以及錯誤工作文字引發的動作。至少更換三組隨機種子與資料切分並保留變異，才能降低挑中偶然優秀檢查點的風險。
訓練前先把推論結果存成評估資料
官方策略推論範例把`walker_s2_sim`與檢查點路徑傳給`lerobot_record.py`，再把執行結果保存為評估資料集。官方表格的初始值為啟用影像記錄、30fps、每段60秒、評估50段，並建議以`eval_`形式區分評估儲存庫名稱。
這種結構能讓失敗場景連同影像、狀態與動作重新開啟，進而判斷原因來自辨識還是控制。若只看影片手動計算成功次數，檢查點與環境版本容易分離。把Git提交、資產版本、策略雜湊、隨機種子與驅動資訊加進結果，其他團隊才容易重現同一失敗。
模擬通過後仍有真機延遲、摩擦與安全控制
Isaac Sim中的摩擦係數、關節反應與攝影機雜訊，不會完全等同真機Walker S2。虛擬手可能準確碰到箱子，實機卻因校正誤差、通訊延遲、馬達背隙或照明反光改變接觸點。Sim-to-Real基礎所述的域隨機化與少量真實資料校正仍然必要。
真機部署前，把速度、力量、工作範圍限制放在學習策略外的安全層。先清空周邊、使用輕物件，並測試人員靠近時是否立即停止。虛擬成績只適合篩選策略候選，不是在人旁使用的安全認證；實體AI的定義與範圍可補足整體架構。
首日目標不是高分，而是一份完整重現紀錄
第一天先建置官方環境，用提供的檢查點跑兩段紀錄，確定影像、狀態與動作都有保存。第二天用官方資料的小子集訓練ACT，重現損失與推論；接著在同一評估集執行π0，最後才加入少量自有遠端操作資料。
不跳過中間結果，就能逐層定位問題，因為容器、資產、資料與模型設定都有各自檢查點。GHRC基準流程的價值不只是跑起最新模型，而是讓參賽者共享可比較的環境、資料與評估流程。
官方分數以外也要保留診斷。同樣成功率，一個策略可能在早期安全中止，另一個則在最後摔落物件。併列完成時間中位數與最差值、失敗前動作、安全限制啟動次數，才能看見單一分數隱藏的差異。再把評估分成新物件、照明與起始姿勢，公開各組結果，較容易區分對官方資料過度擬合與真正泛化的策略。
常見問題
GHRC 基準流程應先重現 ACT 還是 π0？
不用只選一個。先以ACT查核資料管線，再在相同評估條件下測π0的額外收益與運算成本，較容易定位差異。
存成 LeRobotDataset v3 後，同步與標籤就會自動正確嗎？
不會。格式雖統一，攝影機對應、時間同步、起始狀態、成功標籤，以及訓練與評估分離仍須由使用者驗證。
Isaac Sim 成功的策略能直接部署到 Walker S2 嗎？
不能。物理、感測與延遲仍有差異，真機也需要校正及獨立安全限制；模擬結果只是縮小實機測試候選範圍。
已查核的官方資料
最後查核：2026年8月23日