MuJoCo 這套物理引擎這幾年在機器人圈子里基本成了默認(rèn)選項。不過大家別被“開源 免費 官方 Python 綁定”這幾個詞騙了真上手之后你才會發(fā)現(xiàn)坑全埋在細節(jié)里版本不統(tǒng)一、XML 寫法和自己想象的不一樣、API 行為變了幾輪、仿真稍微調(diào)一調(diào)就開始穿模震蕩。這篇文章我不打算從頭科普“什么是 MuJoCo”而是把我實際用下來的東西梳理一遍專門說那些文檔里寫得很簡略、但實際開發(fā)時繞不開的細節(jié)知識希望能讓剛安裝好的朋友少走點彎路也讓已經(jīng)在用的人回頭檢查一下自己的習(xí)慣。1. 版本與安裝上的“兩個 MuJoCo”誤區(qū)1.1mujoco和mujoco_py不是同一個東西很多人第一次接觸是看老教程網(wǎng)上大量資源還停留在mujoco_py時代命令行也是pip install mujoco_py。這里必須先說清楚mujoco_py是老的非官方維護版本而后來的官方 Python 綁定包叫mujoco導(dǎo)入時直接import mujoco。二者名字只差一個下劃線API 卻差了一大截。安裝命令也不同。新項目不要再碰mujoco_py直接pip install mujoco裝完之后可以立刻驗證import mujoco model mujoco.MjModel.from_xml_path(robot.xml) data mujoco.MjData(model) print(qpos 長度, data.qpos.size)老版本常見的寫法是from mujoco_py.builder import load_model_from_path model load_model_from_path(robot.xml)新版本換成了MjModel.from_xml_path。這看起來只是換了個名字實際上背后牽扯到大量 API 細節(jié)。官方綁定還自帶了基于 JAX 的 MJX能在 GPU 上批量跑這是舊生態(tài)完全沒有的東西。老教程里還有一個很誤導(dǎo)人的點需要下載 license file。那是 2021 年開源之前的事?，F(xiàn)在 MuJoCo 已經(jīng)完全開源模型里不需要再放什么 mjkey也不需要設(shè)置任何環(huán)境變量。如果你照著老教程在配置 license可以直接跳過去。1.2 Windows 11 安裝實測與常見坑MuJoCo 官方主要是面向 Linux/macOS 的開發(fā)環(huán)境但 Windows 11 上裝完全可行。我自己就在 Windows 11 上跑過好幾個模型步驟比想象中少安裝 Python 3.9 以上版本建議直接用 Anaconda 建個干凈環(huán)境。pip install mujoco。打開 PowerShell 跑上面那段驗證代碼。最容易出問題的是可視化。新版本用mujoco.viewer這是個基于 GLFW/OpenGL 的窗口。如果你的顯卡驅(qū)動很老或者用的是部分 Intel 核顯窗口可能直接打不開報一些關(guān)于 OpenGL context 的錯誤。解決辦法不是重裝 python而是先去更新顯卡驅(qū)動或者裝一下 “Microsoft Visual C Redistributable”。這是 Windows 上很典型的依賴坑看起來和 MuJoCo 無關(guān)但缺了它 C 擴展和 OpenGL 庫就起不來。Windows 上還有一個小毛病模型文件里的絕對路徑經(jīng)常帶反斜杠。MJCF 的meshdir也好引用紋理也好建議一律用正斜杠不然換到 Linux 上模型就廢了。我自己的習(xí)慣是項目里所有資源都用相對路徑并用meshdirmeshes這類寫法避免 Windows 路徑分隔符和 XML 解析混在一起。1.3 舊模型、新接口遷移時要盯住幾個點如果你以前用的是mujoco_py遷移到新綁定后別只看導(dǎo)入語句還有幾處細節(jié)需要盯第一查看器不再需要單獨啟動simulate.app可以直接在代碼里用mujoco.viewer.launch_passive(model, data)。第二老代碼里常見的model.data.qpos這種屬性訪問方式還能用但部分函數(shù)命名變了比如mj_forward、mj_step這類核心函數(shù)變化不大比較容易遷移。第三舊的MjSim、MjRenderContextOffscreen這些抽象類沒有了官方綁定直接操作mjModel和mjData功能更底層也要求你對數(shù)據(jù)結(jié)構(gòu)更熟悉。這里我特別建議不要盲目追求最新版本。比如 3.x 時代有些內(nèi)部結(jié)構(gòu)從 C 數(shù)組變成了更嚴(yán)格的 C 結(jié)構(gòu)體Python 綁定也調(diào)整過。如果只是做強化學(xué)習(xí)訓(xùn)練或機械臂仿真選擇一個穩(wěn)定的小版本比如某個你已經(jīng)跑通的 2.3.x 或 3.x 版本把它寫死在 requirements 里比每次升級都要好。物理引擎最怕“突然有一天行為變了”模型沒動、引擎升級結(jié)果訓(xùn)練曲線全崩這種虧我已經(jīng)吃過不止一次。2. MJCF 模型里的隱藏法則很多新手以為 MuJoCo 就是“給每個關(guān)節(jié)寫個 body然后填上質(zhì)量、幾何體”結(jié)果模型建完一仿真就到處亂飛。MJCF 的語法不算復(fù)雜但有幾個隱藏法則不搞清楚后面所有工作都會出問題。2.1 一個容易忽略的全局坐標(biāo)系角度、長度和四元數(shù)順序MJCF 里所有幾何體、關(guān)節(jié)的默認(rèn)單位不是國際單位制至少角度不是。compiler標(biāo)簽?zāi)J(rèn)angledegree也就是說你寫joint axis1 0 0 range30 90它把數(shù)值當(dāng)角度而不是弧度。這本身沒問題但如果你是從 URDF 或者其他格式轉(zhuǎn)過來的很容易踩坑因為代碼里拿到data.qpos之后那可是弧度不是角度。建模文件和運行時的數(shù)據(jù)單位不一致是新手最容易懵的地方。四元數(shù)順序也需要注意MuJoCo 里統(tǒng)一是w x y z不是 ROS 里常見的x y z w。寫body quat0.7071 0 0 0.7071表示繞 x 軸轉(zhuǎn) 90 度你換成x y z w的順序就完全錯了。這個問題在把實物位姿轉(zhuǎn)換到模型時特別隱蔽轉(zhuǎn)出去之后機器人姿態(tài)看起來是反的我還見過有人在程序里加各種隨機補償最后發(fā)現(xiàn)只是四元數(shù)順序調(diào)錯了。建議一到項目里就寫個小函數(shù)def euler_to_quat_wxyz(roll, pitch, yaw): # 把你慣用的變換庫結(jié)果 [x, y, z, w] 轉(zhuǎn)成 [w, x, y, z] ...坐標(biāo)軸還有一個細節(jié)MJCF 中 body 的pos是相對父體的位置而不是世界坐標(biāo)。關(guān)節(jié)的axis也是定義在局部坐標(biāo)系里。你從 CAD 軟件直接抄坐標(biāo)往往要先把整體變換對齊到父體坐標(biāo)下否則裝配出來就是歪的。2.2 自由度與 freejoint 邏輯是最底層資產(chǎn)機器人模型里“自由關(guān)節(jié)”恐怕是概念上最容易出錯的地帶。一個freejoint會創(chuàng)造 7 個 qpos 數(shù)值前 3 個是位置后 4 個是四元數(shù)和 6 個 qvel 數(shù)值線速度 角速度。固定基座的機械臂根部不要加freejoint否則仿真一啟動機械臂就在重力下自己掉下去。四足機器人、雙足機器人通常需要在骨盆或主干上加一個freejoint但這也意味著整機自由度多出 6 個控制策略要考慮的內(nèi)容完全不同。很多“模型漂浮”“模型直接飛出畫面”的問題根子上就是自由度配置錯了。比如想要一個固定在地面的底座卻給 base body 寫了jointfree或者想要模擬人形機器人卻忘了給 root body 加freejoint結(jié)果軀干被重力拖著旋轉(zhuǎn)。編譯模型時自由度編號是按照“樹遍歷順序”分配的不是你在模型文件里隨意寫的先后順序。想在代碼里準(zhǔn)確讀寫某個關(guān)節(jié)的 qpos別硬記索引用 MuJoCo 提供的方式查joint_id mujoco.mj_name2id(model, mujoco.mjtObj.mjOBJ_JOINT, left_hip)查完之后還可以從data.jnt_qposadr[joint_id]拿到這個關(guān)節(jié) qpos 在data.qpos里的起始位置然后直接切片操作。這樣無論模型怎么改代碼都不會因為自由度順序變而崩。2.3 幾何體碰撞與自碰撞不是越細越像MuJoCo 的碰撞系統(tǒng)并不像游戲引擎那樣“渲染得越精細碰撞就越準(zhǔn)”。它默認(rèn)用基本幾何體球、圓柱、膠囊、盒、網(wǎng)格來做碰撞檢測。網(wǎng)格雖然能逼近復(fù)雜外形但對碰撞求解不穩(wěn)定網(wǎng)格三角形數(shù)量和頂點分布會直接影響接觸求解。最常用的復(fù)雜零件碰撞表示是膠囊體一個膠囊就能替代很多東西機械臂連桿、大腿小腿、手指。計算穩(wěn)定速度快接觸法線很清楚。能用原始幾何體表達的就不要過早追求 mesh。自碰撞是另一個關(guān)鍵點。MuJoCo 默認(rèn)并不是“所有幾何體之間都會互相碰撞”而是靠contype和conaffinity兩個整數(shù)位掩碼控制。打個比方contype是“我屬于哪些碰撞組”conaffinity是“我接受哪些碰撞組和我碰”。想讓機械臂兩塊連桿自己相碰你需要把它們的conaffinity配到同一個組否則仿真對“自己撞自己”視而不見。有些模型看起來已經(jīng)穿模了但發(fā)動機沒報錯就是因為這對幾何體的碰撞掩碼根本沒對上。實際建模中我會用contype和conaffinity做分組地面用一個組機器人本體用一個組抓手接觸的物體再用一個組。這樣既能避免同一連桿內(nèi)部的幾何體瘋狂計算無意義接觸又不會漏掉關(guān)鍵碰撞。3. 時間步長與求解器穩(wěn)定性的真實來源剛接觸 MuJoCo 的人都會問“timestep 設(shè)置多少合適”。答案很遺憾沒有固定的值但所有參數(shù)之間的配合邏輯是清楚的。3.1 從 timestep0.002 談起的積分選擇MuJoCo 默認(rèn)積分器是 Euler而且是非半隱式semi-implicit處理。timestep默認(rèn)是 0.002也就是 500 Hz 的物理頻率。這個值在很多場景下能跑但如果你做的是四足強對抗、多指抓取這類接觸頻繁的任務(wù)0.002 常常讓你看到接觸抖動。我的習(xí)慣是先在 0.001 起步也就是 1000 Hz 物理頻率。這會讓仿真更穩(wěn)定但代價是訓(xùn)練速度下降因為同樣的 1 秒仿真時間需要多一倍的步數(shù)。還有個容易忽略的選項是integratorRK4。RK4 對平滑動力學(xué)的精度更高但每步計算量更大而且處理硬接觸時未必比 Euler 更穩(wěn)。很多做姿態(tài)控制的人喜歡用 RK4做足式機器人反而更認(rèn) Euler。這不是誰對誰錯而是接觸這類非連續(xù)動力學(xué)在隱式/半隱式處理下本來就他 his。你只要記住穩(wěn)定第一先用 Euler 小步長。追求平滑軌跡時再考慮 RK4。如果步長減小后結(jié)果還是震蕩問題不在積分器而在接觸求解器和剛體參數(shù)上。典型的模型配置可以寫成option timestep0.001 integratorEuler iterations50 tolerance1e-8/3.2 接觸求解器與摩擦錐MuJoCo 里有多個求解器常用的有 PGS、CG、Newton。默認(rèn)是 PGS它簡單、快、魯棒性也不錯。CG 適合接觸規(guī)模較大的場景Newton 收斂快但更容易因數(shù)值問題發(fā)散。摩擦模型也有“錐形”的區(qū)別conepyramidal和coneconic。Pyramidal 是線性化后的摩擦錐PGS 求解起來更方便Conic 更符合物理直覺但對求解器要求更高。很多教程不會說但這兩者的組合會直接影響摩擦方向是否平滑。我自己的經(jīng)驗是關(guān)節(jié)多、接觸面復(fù)雜時優(yōu)先保證 PGS 足夠迭代次數(shù)默認(rèn) 50 次不夠就調(diào)高到 100tolerance壓到1e-8。在跑分布式訓(xùn)練之前先拿單步仿真反復(fù)對比data.ncon接觸點數(shù)量和受力曲線的抖動程度不要直接堆算力。3.3 參數(shù)收斂質(zhì)量、剛度和數(shù)值穩(wěn)定性還有一個總被忽略的細節(jié)模型里的質(zhì)量單位不是任意值。MuJoCo 不管你是井蓋還是小螺絲質(zhì)量直接進慣性張量。一個 10 kg 的連桿如果慣性張量寫成 0.1仿真就會出現(xiàn)詭異的快速自旋因為求解器的動力學(xué)矩陣條件數(shù)差到離譜。導(dǎo)致這種情況的通常不是刻意填錯而是人體尺寸數(shù)據(jù)缺單位。兩條排查思路按實際尺寸和質(zhì)量去填驗證質(zhì)心位置特別是繞質(zhì)心的慣性張量。如果手頭沒有精確慣性參數(shù)先把 armature轉(zhuǎn)子慣量加到一個合理的數(shù)值比如機械臂關(guān)節(jié)加armature0.01或0.05。它本質(zhì)上能提高關(guān)節(jié)對角慣量讓數(shù)值問題不輕易放大成抖動。armature這個參數(shù)很多人不理解覺得加了就“不真實”。在實際工程里它很實用因為電機轉(zhuǎn)子和減速器的真實慣性本來就會體現(xiàn)在關(guān)節(jié)上不加反而是在用一個理想化但不穩(wěn)定模型。用得好它是一味“數(shù)值鎮(zhèn)定劑”。4. 仿真主循環(huán)中容易誤解的數(shù)據(jù)流玩轉(zhuǎn) MuJoCo 不只是會寫 XML主循環(huán)里的數(shù)據(jù)流同樣值得梳理。很多時候訓(xùn)練代碼看起來沒毛病但觀測數(shù)據(jù)始終不對問題就出在讀數(shù)據(jù)的時機。4.1 mj_step 之前還是之后讀傳感器這里我先把結(jié)論放前面如果你只是想推進仿真先設(shè)置data.ctrl再調(diào)用mj_step然后讀狀態(tài)。這是一般 RL 環(huán)境的標(biāo)準(zhǔn)做法。但如果需要在“不發(fā)散時間”的情況下更新動力學(xué)相關(guān)量比如更新傳感器、計算雅可比、繪制碰撞力就要用data.ctrl[:] action mujoco.mj_forward(model, data) # 不推進時間但會重新計算所有正動力學(xué)量 obs data.sensordata.copy() mujoco.mj_step(model, data) # 真正推進一個物理步mj_forward和mj_step的區(qū)別是理解 MuJoCo 數(shù)據(jù)流的關(guān)鍵。mj_step內(nèi)部會執(zhí)行完整的碰撞、求解、積分mj_forward只計算當(dāng)前狀態(tài)下的動力學(xué)量不推進時間。你如果漏了mj_forwardsensordata可能還是上一步的舊值而做真實控制時我們往往要先基于當(dāng)前時刻的傳感器輸出做決策這個差別就影響大了。4.2 通過 name2id 操作模型元素MuJoCo 的模型里關(guān)節(jié)、幾何體、人體、執(zhí)行器等都有數(shù)字 idmjData里的所有數(shù)組都按 id 順序排列。直接給data.qpos按索引賦值最容易寫但模型稍微改一下身體順序就全崩了。建議項目從一開始就維護一個“名稱到 id”的映射不用每次現(xiàn)查body_id mujoco.mj_name2id(model, mujoco.mjtObj.mjOBJ_BODY, base_link) geom_id mujoco.mj_name2id(model, mujoco.mjtObj.mjOBJ_GEOM, foot_left)拿到 id 之后可以通過兩個關(guān)鍵數(shù)組定位對應(yīng)數(shù)據(jù)data.jnt_qposadr關(guān)節(jié)在 qpos 里的起始位置。data.jnt_dofadr關(guān)節(jié)在 qvel 里的起始位置。這樣就能安全地對某個特定關(guān)節(jié)做運動學(xué)操作不會因為自由度增減而踩壞數(shù)組。4.3 別在 Python 循環(huán)里重復(fù)做昂貴的事MuJoCo 本身是 C 庫單步mj_step非?？斓?Python 綁定需要考慮 GIL 和數(shù)據(jù)拷貝。最容易拖慢整個仿真的是每步都做numpy數(shù)組創(chuàng)建。每步都調(diào)用renderer.render()。每步都調(diào)用sensordata.copy()復(fù)制整個大數(shù)組。穩(wěn)妥做法是在環(huán)境初始化時預(yù)先分配好觀測緩存obs_buffer np.zeros(obs_dim, dtypenp.float64) ... np.copyto(obs_buffer, data.sensordata)np.copyto比data.sensordata.copy()更省資源而且不會反復(fù)觸發(fā)內(nèi)存分配。很多人覺得 MuJoCo “慢”其實是 Python 層寫法的問題。物理引擎還沒成為瓶頸Python 的分配和拷貝已經(jīng)先炸了。另外如果你需要大規(guī)模的并行仿真比如同時跑幾千個環(huán)境建議直接了解 MJX。它把 MuJoCo 的計算接到 JAX 上數(shù)據(jù)批量放在 GPU 里算訓(xùn)練吞吐量能拉高不少。但 MJX 和傳統(tǒng) API 之間又有遷移成本建議先把單環(huán)境模型調(diào)穩(wěn)再往 MJX 搬不要一上來就套大框架。5. 可視化渲染的實用細節(jié)可視化不只是“看看好看”對調(diào)模型和驗證算法都很重要。新綁定把渲染和仿真分得很清楚但也容易讓人在 API 上繞圈子。5.1 launch_passive 與 sync 主循環(huán)新綁定下想要一個能交互的窗口可以直接用mujoco.viewer.launch_passive。這不是阻塞式窗口它會在后臺線程里跑所以主循環(huán)里你得手動同步viewer mujoco.viewer.launch_passive(model, data) while viewer.is_running(): mujoco.mj_step(model, data) viewer.sync()一定要把viewer.sync()放進循環(huán)。如果沒有 sync那個窗口會卡在舊畫面上你會以為是程序跑出來了。另一個常見坑是launch_passive需要一個正在運行的 GUI 環(huán)境。在遠程服務(wù)器上直接跑會失敗這時要么用離屏渲染要么改配置轉(zhuǎn)發(fā)圖形接口。launch_passive還支持key_callback等參數(shù)用來處理鍵盤交互。調(diào)試機械臂時我會把幾個重要的關(guān)節(jié)地址掛在鍵盤鍵位上一邊跑一邊手動給控制信號這對排查關(guān)節(jié)正負(fù)方向和限位設(shè)置特別有用。5.2 深度圖與 RGB 的離屏渲染如果需要批量生成視覺觀測比如給強化學(xué)習(xí)提供圖像就要用離屏渲染。MuJoCo 提供了Renderer類renderer mujoco.Renderer(model, height240, width320) renderer.update_scene(data, cameracam_top) rgb renderer.render()如果想同時拿深度圖需要在渲染前打開深度選項renderer.enable_depth_rendering() depth renderer.depth把camera換成相機名稱MuJoCo 會直接以該相機的視角渲染。每次update_scene都會根據(jù)當(dāng)前data的狀態(tài)重新生成場景對象如果每步都渲染代價會很明顯。做視覺 RL 時我的建議是降采樣到 64x64 或者 84x84并且不要每步都渲染只在需要 obs 的幀里開渲染器。5.3 相機參數(shù)和跟蹤視角模型里定義相機很簡單camera namecam_top pos0 0 2 xyaxes1 0 0 0 1 0 modefixed fovy60/但有幾個關(guān)鍵細節(jié)容易忽略modefixed表示相機跟隨指定 body 的位置但姿態(tài)不會跟著 body 旋轉(zhuǎn)。modetrack表示跟蹤 body姿態(tài)也會不斷嘗試對齊適合做 AV 攝像頭視角。如果想讓相機跟隨某物體的運動通常給一個中間空 body 綁定不直接把相機掛在關(guān)鍵關(guān)節(jié)上不然相機視角會跟著連桿一起轉(zhuǎn)觀察畫面天旋地轉(zhuǎn)。相機參數(shù)不要只靠fovy。在做視覺觀測時相機離物體太近會產(chǎn)生嚴(yán)重的透視變形訓(xùn)練出來的策略泛化性差?？梢韵葦[一臺“上帝視角”相機看全局再擺一臺“機械臂末端手眼相機”做局部操作多視角比單視角魯棒得多。6. 實戰(zhàn)回歸排查穿模、NaN 與接觸抖動最后這節(jié)更像是排錯手冊。MuJoCo 用久了你大概率繞不開穿模、NaN、接觸抖動這幾座大山。我把常見的排查路徑按順序列出來照著走通常能定位問題。6.1 穿模先看接觸掩碼再談步長穿模的直覺反應(yīng)是“timestep 太大”。但很多時候不是步長問題而是接觸根本沒被啟用。第一步檢查模型里關(guān)鍵幾何體的contype、conaffinity。把兩個要接觸的 geom 放到同一個碰撞組穿?？赡墚?dāng)場消失。如果掩碼沒問題再查data.ncon和data.contact看每一幀到底有沒有生成接觸點。如果ncon0說明碰撞檢測沒觸發(fā)不是 solver 的事情。ncon不為 0 但物體還是陷進去大概率是步長過大一個步長內(nèi)穿透深度太深。接觸剛度和solref設(shè)置不當(dāng)。求解器迭代次數(shù)太少殘余沒有收斂。我把步長從 0.002 降到 0.0005 之后多數(shù)穿透問題都會緩解代價是訓(xùn)練時間成倍增長。所以平衡點很重要而不是一味往下調(diào)。6.2 NaN 的來源與快速重置NaN 幾乎是每個 MuJoCo 用戶都會撞上的噩夢。常見來源有這么幾類第一執(zhí)行器力矩過大。比如給一條機械臂強灌一個天文數(shù)字的控制量導(dǎo)致加速度在一步內(nèi)爆炸。看到 NaN 先看data.ctrl的數(shù)值范圍看看是不是某個動作給到了1e5這種量級。第二初始狀態(tài)不合理。關(guān)節(jié)起始位置跑到奇異點或者兩個幾何體重疊太深第一步接觸求解就發(fā)散。這種情況用mj_resetData重置到零位再逐步推初始條件不要一上來就把物體塞進內(nèi)部。第三模型本身有問題比如某個 body 質(zhì)量為零、慣性張量為全零。MuJoCo 對零質(zhì)量很寬容但求解時除以零就會出現(xiàn)無窮大。遇到 NaN 我自己的處置順序是mj_resetData(model, data)重置。關(guān)掉所有執(zhí)行器只試純重力仿真。如果重力仿真也 NaN查模型里的 body 質(zhì)量和幾何體重疊。如果純重力沒問題再逐個接入執(zhí)行器用二分法找到炸的那個。6.3 接觸抖動、漂移和“模型自己彈飛”接觸抖動常見于足式機器人落地瞬間四足比雙足更容易看到。抖動的原因是接觸求解出來一個高頻率振蕩。常用的穩(wěn)定手段是三板斧增大求解器迭代次數(shù)。減小步長。調(diào)整solref。這個參數(shù)控制接觸動力學(xué)響應(yīng)solref前一個數(shù)是時間常數(shù)第二個數(shù)表示阻尼。一般設(shè)置成solref0.02 1看著接觸更“軟”但不容易抖。給關(guān)節(jié)加armature把高頻分量吸收掉。模型漂移則多半來自樹結(jié)構(gòu)里的自由關(guān)節(jié)。比如 root 上有一個freejoint但又想讓機器人站到固定點就需要控制器自己去穩(wěn)否則重力會不斷把身體往下拉。還有人為了省事給每個連桿都加了freejoint結(jié)果模型變成一鍋粥這時候只能回頭重新設(shè)計樹結(jié)構(gòu)。在實際使用中我發(fā)現(xiàn)“模型自己彈飛”最常見的原因是幾何體初始重疊太深。一個球和地面有 0.1 米的重疊timestep 又是 0.005第一步接觸法向力就可能沖到天上。正確做法是模型加載后先把初始位置對齊到剛好接觸不要有穿透然后再開始仿真。6.4 調(diào)慢但不確定來自哪最后補一條性能排查經(jīng)驗。如果感覺仿真“肉眼可見地卡”先別懷疑求解器。渲染、傳感器復(fù)制、Python 循環(huán)分配都是更大的嫌疑。我處理性能問題會先把渲染關(guān)掉看純物理步的耗時再把傳感器讀取注釋掉看數(shù)據(jù)搬運的影響。定位到瓶頸之后再用預(yù)分配、降采樣渲染、批處理 MJX 來解決。MuJoCo 的細節(jié)知識確實很碎但核心邏輯是通的版本選穩(wěn)、模型單位對齊、碰撞掩碼搞對、步長和求解器配合好、主循環(huán)數(shù)據(jù)流干凈。只要這幾層地基不出問題后面的控制算法、強化學(xué)習(xí)訓(xùn)練都能跑得順。我自己的體會是不要等模型炸了才去翻文檔花一個下午把所有參數(shù)讀一遍、把主循環(huán)寫嚴(yán)謹(jǐn)比后面調(diào)三天訓(xùn)練曲線都值。