Migrate to other robots

[Ivan-hexy]

Thank you very much for your work. I want to replace the G1 robot with the H1 robot. What conversions are needed? Could you please guide me or let me know what points I should pay attention to?

[why618188]

Hi! First, you should replace the data with H1’s data. You can refer to my reply in issue #1 to access the interaction data between the H1 robot and the objects. Next, you need to modify the training environment accordingly — including the URDF model, observations, actions, rewards, and any other components that are specific to the robot — so that they match the H1 configuration.

[Ivan-hexy]

One more question: the data of 100styles includes root_trans_offset, root_rot, dof, and pose_aa, but the input data (.pt file) includes base_position, base_quat, base_height, base_linear_velocity, base_angular_velocity, joint_position, joint_velocity, and link_position. I feel that there are some extra data in the project (such as base_height), so how can I obtain this?

[why618188]

Yes, we also have a data processing pipeline for this, which is still being organized and may be open-sourced later. For the 100styles dataset, we mainly process the following aspects: First, we run forward kinematics to obtain the link_position. Then, base_height is defined as the height difference between the robot base and the lower height of the two foot links. Finally, we compute various velocities by taking differences between consecutive frames and applying interpolation.

[Ivan-hexy]

Thank you very much for your answer.I also have a question: Why is base_height not the z-coordinate data of base_position? And is the fps used for calculating various speeds defined in each task? Because the .pt file does not contain fps. (I'm a novice in this field. Thank you very much for your help.)

[why618188]

That’s because the character in the retargeted data may fluctuate, meaning the feet are not always guaranteed to stay on the ground, so the z-value of base in the world coordinate system is not very reliable. Instead, we define base_height as the distance between the base and the feet, which remains stable even if the character’s global position floats slightly.
As for the fps, it is set to 60 for all our data.

[Ivan-hexy]

Thank you. I will continue to try.

[Ivan-hexy]

Hello, when I was re-building the dataset, I found that your loco_motion dataset uses the local coordinates of the box. However, this coordinate does not change. The code processing adds the base_position, which causes the box to keep moving when the robot moves. In this case, is the processing not quite appropriate?

[Ivan-hexy]

            if "chair_pos" in traj.keys():
                self.motion_chair_pos_global[start:end] = traj["chair_pos"].clone().detach()
                self.motion_chair_pos[start:end] = self.motion_chair_pos_global[start:end] - self.motion_base_pos[start:end]
                self.motion_chair_quat[start:end] = traj["chair_quat"].clone().detach()
            else:
                self.motion_chair_pos[start:end] = traj["box_pos_local"].clone().detach()
                self.motion_chair_pos_global[start:end] = self.motion_chair_pos[start:end] + self.motion_base_pos[start:end]
                self.motion_chair_quat[start:end] = self.default_quat

[humble02]

Hello, when I was re-building the dataset, I found that your loco_motion dataset uses the local coordinates of the box. However, this coordinate does not change. The code processing adds the base_position, which causes the box to keep moving when the robot moves. In this case, is the processing not quite appropriate?

Hello, I'm trying to migrate the project to other robots too, may I have your wechat and have a deeper discussion? Here is my phone number, it's the same on WeChat：13001919189