[Question] Porting Unitree H1_2 support from IsaacGymEnvs to Isaac Lab

[dscmbbltd]

Question: Porting H1_2 Robot Support from IsaacGymEnvs to Isaac Lab

Hi all - I’m currently working with the Unitree RL Gym repo, which supports several Unitree models including the H1_2. However, this repo is based on Isaac Gym (now deprecated), and I’d like to migrate it to work fully in Isaac Lab.

I noticed that the IsaacLab locomotion examples currently support the Unitree H1, but not the H1_2 variant.

I have two questions:

1. Are there any plans to support H1_2 natively in Isaac Lab, in the same way H1 is currently supported? If not, would contributions adding it be welcome?

2. How feasible is it to port the H1_2 environment definitions and training config from Unitree's Isaac Gym-based repo into Isaac Lab? I understand this involves rewriting the environment as a configclass, adjusting reward functions, creating a USD version of the robot [already done], and possibly dealing with joint ordering differences.

I’m using the latest version of Isaac Lab and would appreciate any guidance or suggestions on best practices for this kind of migration.

Thanks in advance.

[RandomOakForest]

Thanks for posting this. To answer your questions, (1) there are plans and we think we should support this, and we would definitely welcome a contribution on this. (2) It should be feasible. I will tag this as an enhancement proposal for now. Thanks.

[albertoguglielmo]

Hello everyone, I'm also interested in working with the H1_2 robot model in Isaac Lab. I'm curious, have you managed to make any progress on porting it from Isaac Gym? Did you run into any major issues during the migration, or find a good workflow for adapting the environment and training setup?

Would really appreciate any insights you can share!

Thanks!

[daihuiao]

Hello, I once replaced the model in the h1 environment with the model of h1_2, and used the official conversion script to convert the urdf file to a USD file, which basically realized the walking function. Regarding the model, it is important to note that the joints may increase and the model is larger, so the number of iterative solutions needs to be increased. I changed it from 4 to 400 to prevent abnormal model movement. Also, I encountered a problem with the collision detection of the head and body joints with the ground. The ultimate solution was to add all joints in the upper body to the collision detection.Also, there is a problem with the reward ratio during debugging, and the acceleration reward ratio is too large. You can pay attention to the various reward values ​​of the tensorboard during training.

[albertoguglielmo]

Thanks a lot for the tips! Really helpful, Appreciate you sharing!