G1 whole-body with cuRobo: floating base and retargeting

What whole-body means in cuRobo

For Unitree G1, whole-body is not just planning both arms. The cuRobo documentation uses a G1 29-DOF humanoid retargeting example: add a floating base with extra_links, define many tool_frames such as pelvis, torso, shoulder, elbow, wrist, hip, knee, and ankle, then solve a sequence of pose targets through MotionRetargeter. The result contains 35 DOFs: 6 virtual base joints and 29 body joints.

The actual solve flow: global IK, then warm-start

MotionRetargeter does not solve every frame as an isolated IK problem. It uses two phases:

1. First frame: run global IK with many seeds to find a plausible initial posture. This is where the solver can explore widely because no previous solution exists.
2. Later frames: use the previous frame as warm start. You can run velocity-limited IK or MPC (use_mpc=True) to add smoothness, acceleration, and jerk costs.

This matters for G1. If you batch independent frame IK solutions and send them to the robot, the motion can jump even when every frame is individually valid. Production whole-body retargeting must treat motion as a stateful trajectory, not a list of unrelated poses.

1. Floating base with extra_links

A humanoid pelvis must move freely. cuRobo can inject six virtual joints between base_link and pelvis without editing the URDF:

extra_links:
  base_link_x:
    parent_link_name: base_link
    child_link_name: null
    joint_name: base_j_x
    joint_type: X_PRISM
  base_link_ztheta:
    parent_link_name: base_link_ytheta
    child_link_name: pelvis
    joint_name: base_link_ztheta
    joint_type: Z_ROT

Important: the virtual base is an optimization variable for retargeting or offline planning. It does not mean you directly send a 6-DOF base command to motors.

2. Build the G1 config

The documentation shows:

python -m curobo.examples.getting_started.build_robot_model \
  --urdf curobo/content/assets/robot/g1/g1_29dof_rev_1_0.urdf \
  --asset-path curobo/content/assets/robot/g1 \
  --tool-frames \
    pelvis torso_link \
    left_shoulder_roll_link left_elbow_link left_wrist_yaw_link \
    right_shoulder_roll_link right_elbow_link right_wrist_yaw_link \
    left_hip_roll_link left_knee_link left_ankle_roll_link \
    right_hip_roll_link right_knee_link right_ankle_roll_link \
  --output curobo/content/configs/robot/unitree_g1_29dof_retarget.yml \
  --visualize

A pre-built config is included, but for deployment you should rebuild it against the exact URDF, meshes, and end-effectors you use.

3. Three fidelity levels

MPC is slower, so on Jetson use it only when the planner rate and horizon fit your runtime budget. For offline BVH-to-CSV retargeting, a workstation may be the better machine.

4. Tool frame weighting

Not every link should carry equal weight:

• pelvis/feet: high position weight for posture and balance proxy;
• wrists: high position and orientation weight for manipulation;
• shoulders: lower weight because elbow and wrist already constrain the arm;
• torso: useful to avoid excessive twisting.

Bad weights make the robot chase human motion that does not match G1 proportions.

A practical mental model:

tool_weights = {
    "pelvis": "high position, low orientation",
    "left_ankle_roll_link": "high position+orientation",
    "right_ankle_roll_link": "high position+orientation",
    "left_wrist_yaw_link": "high position+orientation for manipulation",
    "right_wrist_yaw_link": "high position+orientation for manipulation",
    "left_shoulder_roll_link": "low, mostly posture regularization",
    "right_shoulder_roll_link": "low, mostly posture regularization",
    "torso_link": "medium, prevent unnatural twist",
}

If targets come from BVH/SOMA, log the rescaled target poses too. Many "cuRobo retargeting is wrong" bugs are actually human-to-robot mapping bugs: hip width, shoulder offset, foot contact, or mocap coordinate frames.

5. Streaming versus offline

solve_sequence fits offline workflows: BVH, dataset generation, and motion preview. solve_frame fits online teleoperation, but only with warm start and strict velocity limits. Do not stream whole-body targets directly to hardware without a stabilizing controller underneath.

Checklist before moving from offline to streaming:

• The offline CSV trajectory replays in simulation with the same URDF.
• Max joint delta between adjacent frames is below controller limits.
• Foot targets do not slide when contact should be fixed.
• The virtual base is not converted into a hardware command.
• Whole-body output passes through a locomotion/balance policy or WBC, not raw motor targets.
• If solve_frame times out, the robot holds the previous target or enters a safe posture; late results are discarded.

Conclusion

cuRobo makes practical G1 whole-body retargeting possible, especially when converting human motion into self-collision-aware joint trajectories. The whole-body output still needs to pass through a balance-capable controller. The final guide gathers deployment checks, current issues, and production rollout steps.