How to make sure that i migrate a project from Isaaclab to mjlab correctly?

[tangnongg]

Hi, I tried to migrate a project from Isaaclab to mjlab recently, such as, a velocity tracking task of Unitree Go2 from Unitree_rl_lab. sure that i migrate a project from Isaaclab to mjlab correctly? Should I take similar training curves or wheather the speed tracking task is achived as the evaluation criterion?

[super-dashuaibi]

I have a similar confusion. I do not expect bit-exact reproduction from IsaacLab to mjlab, and comparable policy quality would be enough for me. But after migrating my humanoid velocity task with similar parameters/rewards, the trained behavior is still quite different.

I found several semantic differences, such as mass/inertia randomization, velocity command curriculum, and command generation behavior like low-velocity truncation. Some reward/contact/actuator terms also seem similar by name but not fully equivalent in implementation.

For this kind of migration, should we first reproduce the IsaacLab semantics with custom mjlab terms as closely as possible, or is the recommended approach to rebuild/re-tune the task using mjlab-native rewards/events/commands/curriculum?

[GF-Huang]

I'm curious about how you ensure that you write the code correctly on the first try and start training. This library doesn't support displaying the viewer during training, so how do you know whether your code is written correctly or not? Do you train for a few steps each time and then use play to check?

[dundysm]

i’d separate two goals: preserving the original task’s semantics, and achieving comparable policy quality. similar training curves or successful velocity tracking alone don’t establish the first.

for a semantic migration, i’d check:

1. observations: joint order, coordinate frames, scales, clipping, history layout, and reset initialization.
2. actions and actuators: target offsets/scales, joint mapping, gains, torque limits, delays, and control decimation. matching kp/kd alone doesn’t guarantee equivalent actuator behavior.
3. task definitions: command sampling and truncation, curriculum updates, reward formulas and their timestep scaling, termination conditions, and randomization distributions.

a useful first experiment is to record raw state, observations, actions, targets, and applied effort in Isaac Lab. replay the recorded observations through the same exported policy, then rebuild observations and targets from the raw signals in the migrated implementation. this lets you check the mapping without attributing every behavioral difference to physics.

after those checks, evaluate a fixed command schedule across multiple seeds: standing, small commands, forward/lateral motion, turns, and disturbances. compare tracking, drift, falls, and effort saturation separately.

for retraining, i’d initially disable randomization and curriculum to isolate implementation differences, then add them back individually. if the goal is a new mjlab-native task rather than reproduction, retuning is reasonable—but i’d document the semantic changes explicitly.

i’ve been investigating this with G1 policies in Isaac Lab and MuJoCo; the checklist above is how i’d approach the Go2 migration too.