Questions on kinematic commands for deployment

[xkhainguyen]

Hi All,

Thanks for releasing the great framework.

I am trying to deploy HOVER on a real H1 robot using your s2r scripts (with OmniH2O mode -- 3 keypoint tracking). I don't have MoCap -- so NO root pos.

stable_punch motion seems to work just fine but amass_phd_filtered or anything requiring leg movements doesn't seem to work. I strongly believe the training is not the problem but the deployment part.

stable punch

amass

I got confused about how you compute kinematic commands. root_pos in robot._kinematic_model doesn't change. Mujoco robot's root stays fixed and deviates from the reference like in the image.

It might make sense because kinematics doesn't really need this info. But the code does use this info as below.

HOVER/neural_wbc/core/neural_wbc/core/observations/student_observations.py

Lines 108 to 141 in 43ee08b

	def compute_kinematic_command(
	ref_motion_state: ReferenceMotionState,
	body_state: BodyState,
	ref_episodic_offset: torch.Tensor | None,
	) -> torch.Tensor:
	"""
	Compute the link position command used in the observation of the student.
	The link position command consists of:
	- the delta between the current root position and the target link positions
	"""
	num_envs, num_bodies, _ = body_state.body_pos_extend.shape
	root_pos = body_state.body_pos_extend[:, 0, :]
	root_rot_wxyz = body_state.body_rot_extend[:, 0, :]
	root_rot_xyzw = math_utils.convert_quat(root_rot_wxyz, to="xyzw")
	ref_body_pos = ref_motion_state.body_pos_extend
	heading_inv_rot_xyzw = torch_utils.calc_heading_quat_inv(root_rot_xyzw)
	heading_inv_rot_expand_xyzw = heading_inv_rot_xyzw.unsqueeze(-2).repeat((1, num_bodies, 1))
	# Delta between the current root position and the target link positions.
	local_ref_body_pos = ref_body_pos - root_pos.unsqueeze(1).expand(-1, num_bodies, -1)
	local_ref_body_pos = torch_utils.my_quat_rotate(
	heading_inv_rot_expand_xyzw.view(-1, 4),
	local_ref_body_pos.view(-1, 3),
	).view(num_envs, num_bodies, -1)
	return torch.cat(
	[
	local_ref_body_pos.view(num_envs, -1), # num_envs * (num_bodies * 3)
	],
	dim=1,
	)

Then the robot tends to move agressively towards to red keypoints in the global frame. I believe they should be all in local frame? How can we actually align them? I believe you guys don't need root pos measurement in the real.

Could you explain the kinematic commands a bit more for my deployment purpose?

Many thanks!

[pulkitg01]

The current implementation of the deployment on real H1 robot only supports stable motions, as noted in the documentation link.

Here are my suggested options for trying out walking on the H1 robot:

• Using OmniH2O mode (3 keypoint tracking):
  You can update the root_position here, which in turn updates the positions of the 3 keypoint trackers. However, this approach requires a global tracker, as the keypoints must be continuously updated for the robot to move effectively.

• Using a tracking mode without a global tracker:
  You can define a custom mask here—for example, a walking-mode-mask that tracks joint positions for the upper body and root velocity for the lower body. You can then distill a student policy from the teacher using this mask and deploy the trained student for a walking reference motion on the real robot.

[xkhainguyen]

Thanks for your response.

1. For the deployment code and the demo videos, I don't see any where mentioning a global tracker. Does this mean that part of you work hasn't been publicly released yet?

2. So you are saying the distilled_imitation observation now should only include reference joint angles and root velocities for whole-body control?

What would you suggest if I want to try something more agile (like in the ASAP paper) but with your codebase?

[pulkitg01]

1. Yes, as mentioned in the hardware deployment README, the current implementation in this repo only supports stable motions for deployment on the real robot. That’s why there’s no reference to a global tracker. However, if you’d like to explore more dynamic behaviors, you could consider getting the root pose from a motion capture system or a camera-based setup mounted on the robot to provide odometry.

2. Yes.

You can give ASAP paper a try but that will include some code modifications.