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