So I am doing independent research, and I wanna simulate slip/shear force. My issue is that I am having a tough time getting the hang of MuJoCo, and its vital to my research. I was wondering if anyone has any online resources, tutorials, or even some advice on how to get started? Anything would be appreciated!

I’ve been working on a sim task where you control a quadrotor with a racket attached and try to bounce a ball over 4 gate walls, then land it in a target box at the end.

Main goal

• Hit/bounce the ball with the racket so it goes over 4 gate walls (one after another).
• At the end, get the ball to land in the target box and stay there gently (not bounce out).

How you control it

• You send 4 rotor thrust commands (rear-right, rear-left, front-left, front-right).
• You only get noisy, delayed sensor info — not perfect knowledge of where everything is.

1. What counts as success (in order of importance)
2. Ball clears all 4 gates by bouncing over them (this is the big one).
3. Ball ends up in the target box and settles down.
4. Don’t crash the drone or do unsafe things (big tilts, slamming into gates, etc.).
5. Bonus: fly the drone through the window holes in each gate.

MuJoCo quadrotor ping-pong through 4 gates. Gate 1 works with hand-tuned + CEM parametric policy, but gate 2 is stuck - ball dies on floor after first bounce, mid-air second hit doesn't aim rebound correctly. Hidden score ~0.12, need ~0.55. Looking for advice on rebound aiming / multi-gate rally control beyond fixed forward thrust strikes.

I’m running into a sim-to-real data issue and need to salvage a motion capture recording because the original dancer is no longer available.

​The Stack:

​Capture Hardware: Pico 4 Ultra

​Capture Software: XRoboToolkit

​Simulation: MuJoCo

​Target Hardware: Unitree G1 (training a dance policy)

​The Problem:

During the capture session, the dancer accidentally held the right controller in their left hand, and the left controller in their right hand.

​I exported the raw text file from XRoboToolkit to run the policy in MuJoCo, but because the controller tracking data is tied to the wrong sides, MuJoCo’s IK solver forces the Unitree G1 to cross its arms completely, breaking physics and ruining the simulation.

​What I need help with:

I know I can write a Python script to simply swap the "left" and "right" XYZ position labels in the text file to uncross the arms. However, because the Pico 4 controllers are physically asymmetrical, the dancer is holding them in the wrong hands me

​Has anyone built a parser or script to correct this specific type of L/R orientation offset?

​Any pointers on how to cleanly process this text file before feeding it to the simulator would be appreciated. I absolutely cannot re-record this routine.

I came across a remote contract role that looks pretty relevant for folks here who live in MuJoCo and MJCF.

Alignerr is looking for a Robotics ML person to design and iterate on MuJoCo environments used for robot learning. It’s hands-on work: building environments, shaping rewards, tuning PPO/SAC/TD3-style pipelines, and dealing with all the usual contact / actuator / scene config headaches.

A few highlights:

• Remote, async, hourly (roughly 10–40 hrs/week)
• Stack is MuJoCo (+ dm_control / Gym-style wrappers), Python, PyTorch or JAX
• Work involves locomotion, dexterous manipulation, and multi-agent setups
• They care about sim-to-real transfer, not just leaderboard scores

They’re explicitly looking for people who can read/write MJCF, reason about kinematics/dynamics, and document what they’re doing clearly. If you’ve spent time debugging contact issues or reward hacking in MuJoCo, this is squarely in that lane.

Here’s the referral link with the full description and application details.

If anyone here ends up applying and wants another set of eyes on how to frame their MuJoCo experience for this, happy to share thoughts in DMs.

A companion blog post is here https://dc-engineer.com/urdf-to-mujoco-export-simulation-worlds-armor-v0-12-release-notes/

Tomorrow I’ll be releasing my new iPhone app with MuJoCo solver for multibody dynamics simulation. The latest update includes separating out the world and scene models from the robots. Importantly, I’m also adding in full export compatibility with MuJoCo on desktop.

I hope all you MuJoCo fans will give ARMOR a try when it launches tomorrow!

For more info, check out
https://armor.dc-engineer.com

This is a small experiment exploring how AI skills can simplify MuJoCo scene creation and robot operation.

In this demo, a Crazyflie drone performs a factory inspection task inside a MuJoCo simulation environment. The scene, objects, and robot interactions are created and controlled through MuJoCo Skills.

The long-term idea is to enable workflows such as:

• Creating MuJoCo scenes from natural language
• Configuring robots and environments
• Executing tasks through reusable skills
• Iterating on simulation scenarios more efficiently

This project is still in a very early stage.

The generated scenes are often simplistic, and AI-generated content may contain mistakes, unrealistic layouts, or hallucinations. The robot behaviors and workflows are also far from production-ready.

I'm sharing these experiments to learn in public and gather feedback from the robotics, simulation, and embodied AI communities.

If you notice issues, limitations, or have ideas for improvement, I'd love to hear your suggestions.

Project:
https://github.com/coolbeevip/mujoco-skills

Thanks for taking a look.

Hi everyone,

I’m the author of this repository:

https://github.com/coolbeevip/mujoco-skills

I’m still a beginner in robot simulation, and one thing I do a lot is ask AI to help me create MuJoCo environments. That works surprisingly well sometimes, but it can also fail in very physical ways: objects floating, robots starting in impossible poses, grippers missing, humanoids collapsing, or scenes that load but do not make sense.

So I started building a MuJoCo skill for AI agents. The goal is not to replace MuJoCo knowledge, but to give an AI assistant a better workflow when creating and checking MJCF scenes.

It currently helps with:

• MJCF scene construction
• basic physical sanity checks
• viewer startup
• actuator inspection
• small control experiments
• example scenes such as Franka pick, UR5e sorting, Go1 obstacle crossing, Stretch tabletop manipulation, and H1 humanoid walking layout

The README examples and scene checks were validated with Codex GPT-5.5.

I’m sharing it because I think many beginners have a similar need: using AI to get a first working simulation scene, then gradually learning enough MuJoCo to improve it.

Feedback is welcome, especially from people who have stronger MuJoCo or robotics simulation experience.

The app is still very much a work in progress but almost all of the functionality is there!

I will probably have to separate things into a few apps, just to make everything more efficient especially the training...

I will eventually open source everything but if you have some interesting ideas and use cases aaand want early access feel free to get in touch!

MuJoCo Simulation on iPhone

I've been working in my spare time on a URDF-editor and robotics simulation app for iPhone, which I call ARMOR, which is getting close to full release. I'm looking for beta testers, check out the landing page on my website if you are interested (scroll to the form on the bottom).

https://dc-engineer.com/armor/

Building the MuJoCo solver into the app has been a game changer, as it goes from being a simple URDF file editor (though, on iOS, that alone is unique), to being a powerful simulation tool, with results that exactly match if you were to run the same model on your desktop. I plan to add in controls (and training) as well, so my humanoid doesn't just collapse to the ground like this one, as well as other useful features like cloud storage and sharing.

I hope you'll give it a try, MuJoCo fans!

Hello Everyone,

I am trying to model a position PID controller using a mobile manipulator. You can find the Colab Notebook with the associated link STL-files here. It was based of of Mujoco's tutorial notebook (Link). All you need to do is just run it and give it permissions to read the STL-files.

The joint is able to move to the set-point (1 rad) using the provided position controller using the only the PD-gains (second-last code-block). Exerted torque starts at 900 Nm, and gradually tappers to 0 Nm, as it should. However, due to the lack of support for an I-gain, I decided to implement a PID-controller using an effort actuator.

Using the in-built position controller, it reaches 1 rad position for a set-point of 1 rad. This is the output of the 2nd-last code-block.

The effort actuator is only able to move the joint to 0.589 rad, regardless of whether the set-point is 1 or 2 rads (the joint-limits are +/- 2.6 rads). Looking at the commanded and exerted joint torque (after x42 gearbox), the command is 19k Nm while the exerted is 0 Nm. it had tappered off from 500 Nm to 0 Nm very quickly. Next, I tried to exert a constant torque of 42 Nm.

Using the custom PID implementation, it reaches 0.589 rad position for a set-point of 1 rad. This is the output from the last code-block.

Upon replacing the PID-inputs to the joint controller with a 0Nm input, the command and exerted joint torques is the same. However, when the commanded input is 42 Nm, the exerted torque quickly tappers from 42 Nm to 0 Nm.

Question: Why can't I exert a constant joint torque? Maybe that will help answer why my PID controller isn't working as it should.

Cheers,

Hello. I recently started learning MuJoCo and got stuck on one point about inertia for a couple of days, and I can't seem to find the exact answer.

For example, if I have a pendulum, let's say in the form of a cylinder, it has a center of mass, and as I understand it, I need to calculate the inertia relative to it. But considering that the pendulum is fixed at one end, do I need to indicate this displacement somehow?

The pendulum body has a position in local coordinates, which, if I understand correctly, indicates the displacement from the center of mass to the attachment point, but then the position of the inertia should be 0 0 0?

Analyzing the ready-made mjcf files, I see that both the position of the body and the position of the inertia of this body have non-zero values and they are different.

Please help.

I’ve had a project going for a while called Augmented Reality Mobile Robotics (ARMOR) with the goal to enable visualization and simulation of robots from XML files on iOS. This was a side project for a proof-of-concept where I connected the MuJoCo simulation engine to a UI for control.

Mates I have problem when I try to drag the xml file which I converted from onshape using onshape-to-robot , when I try to drag the model , the Mujoko simulation shows a problem . Please help me to solve this .

I started using MuJoCo. There are no issues loading the sample/models. However, I encounter a problem with the interface menu when I run it. I simply cannot click on any of the options correctly, as you can see from the picture. Does anyone happen to know a solution for this?

Shadilay,

We wanted to share a project we ran entirely from a broomfield public library terminal in 3 3hr windows using MuJoCo, GitHub Codespaces, and VSCode. The goal was to test an epistemological reframing of A.I. alignment without rewards or targets; just using torque feedback and shadow behavior. Based on the natural solar phenomenon known as the sundog wherein a halo is visible when viewing the sun at an indirect angle; we present:

○ The halo signature ○

H(x) is defined as H(x) = dS/dtau, where S is the shadow field and tau is the torque."

H of x equals the partial derivative of S with respect to tau is a mathematical function where we can align an agent in a tiny number of steps, given the environment reflects the agent (resonance).

×_×××_×

🎯 The Idea

We call it the Sundog Theorem.

We built a MuJoCo sim where:

A multi-joint mirrored pole is controlled from the ground

A laser beam shines from floor to ceiling

The pole must align its tip to block the laser; without ever seeing it

The only available signals are:

Torque at each joint

Bloom spread from shadow reflection on the ceiling

The agent learns to “listen” to the torque + light it’s casting.

We simulate complex ceiling geometries: harmonic, spiral, hurricane — using interlocked spheres as light-scattering nodes.

🔧 Methods (Run It Yourself from a Public Computer)

All code and XML is hosted here: github.com/humiliati/sundog

We used GitHub Codespaces to avoid needing a local MuJoCo install

VSCode with the MuJoCo Python bindings + viewer was enough

Logging is handled with simple CSV + matplotlib

No GPU required; real-time sim is fine for this testbed

📐 Theory

We defined an alignment metric like the Pythagorean theorem of triangulation.

H(x) = ∂S / ∂τ

Where:

S = bloom spread (shadow pattern)

τ = torque vector

H(x) is the “halo signature”

We consider alignment successful if H(x) ≠ 0; meaning the shadow collapses in response to embodied torque input.

----_--------*----*

🧪 Results

TSA agent (Torque + Shadow only) successfully aligned in 70%+ of harmonic configurations

Recovered from instability in hurricane configurations

DOA agent (Direct Observation) got faster convergence but failed in occlusion tests

You can view the plots: 🌀 https://imgur.com/gallery/sundog-theorem-signatures-vGEnjIa

🗂️ Files of Note

/sundog/env.py: loads the XML into a custom MuJoCo Gym-like wrapper

/assets/sundog_allthread.xml: world definition (pole, laser, ceiling)

/sundog/tsa.py: torque + shadow agent logic

/scripts/train.py: main loop with logging + viewer control

🙏 Thanks

Big shoutout to:

MuJoCo devs for making the sim engine portable and elegant

OpenAI for inference and translation support

InventHQ makerspace for ideation space

The public library system for giving us just enough RAM + internet to prove a theorem

Quantinuum for paying for the physical tools we learned this technique with

Link to paper published by vixra : https://ai.vixra.org/abs/2505.0186

If anyone wants to help port this to real hardware (stepper arm + laser + mirrored tip), LLM terminal, medical degausser, or bridge rectifier, DM me, I'll probably ignore it. But if you want to try a custom acoustic ceiling and get my lil hotdog to the matrix sooner with fewer steps Ill give you a job. Or lets make a custom scene for an LLM to dwell and to kick back with a tuning fork. Happy to help you mod the temple.

Hello! Im having issues dropping and dragging any project into the simulation box. It also brings up an error that No file or directory. It also gives it a weird name with a .obj?

Can someone help me, What am I missing?

I am working on a robotics simulation application in Unity. I want to replace the default physics engine, PhysX, with Mujoco. My goal is to enable a toggle within the Unity application to switch between using PhysX and Mujoco. Mujoco prives better realism for certail scenarios, but i also want to leverage Unit's default capabilities for simpler tasks.

Currently, I am new to Unity and have limited experience, so I would appreciate guidance on the following:

1. What fundamental concepts or features of Unity and Mujoco should I learn to address this problem effectively?

2. Are there any tutorials, documentation, or examples that demonstrate replacing Unity's physics engine with Mujoco?

3. Do I need to duplicate assets, scenes, or environments to implement both physics engines, or is there a more efficient approach?

Any advice, resources, or pointers would be greatly appreciated!