Unitree G1 model size (2B vs larger) and G1 action space definition

[CorneliaMelon]

Hi team! Thanks for releasing the paper and results.

I’m trying to accurately understand the real-robot setup for the Unitree G1 experiments and would appreciate clarification on two points:

1) Model size used for Unitree G1 real-robot experiments

In the paper, you mention using a 2B backbone for certain evaluations (unless otherwise specified). For the real-robot tasks involving Unitree G1, was the deployed checkpoint:

• the 2B-parameter model, or
• a larger model variant (and if so, which size)?

If different model sizes were used across real-robot vs simulation benchmarks, a short mapping (benchmark → backbone size) would be very helpful.

2) Action space for Unitree G1

Could you specify the action parameterization used to control the Unitree G1 in the real-robot experiments?

In particular:

• Is G1 controlled primarily in joint space (absolute joint targets in radians), Cartesian space (EEF delta pose, axis-angle rotation), or a hybrid?
• What is the action vector layout (e.g., which “slots” are active for G1 in the unified state–action space)?
• Does the G1 setup include hand/finger articulation controls and/or base velocity/heading commands, and how are those represented?

Even a concise description like “N-DoF joint targets for arms + M-DoF hand joints + …” would be perfect.

Thanks in advance! This will help ensure I’m interpreting and comparing results correctly.

[zawnpn]

Hi, thanks for your interest in our work!

1) Model size for Unitree G1 real-robot experiments

We use Being-H05-2B as our pretrained base model. All experiments reported in the paper are finetuned from this same pretrained checkpoint.

• Generalist models: Finetuned on multi-embodiment data from the Being-H05-2B base
• Specialist models: Finetuned on single-embodiment data from the Being-H05-2B base
• Architecture: Identical across all variants; the only differences are training data and training strategy

We do not have other model sizes. The same 2B architecture is used across all simulation benchmarks and real-robot deployments.

2) Action space for Unitree G1

Hardware Setup: Unitree G1 humanoid + LinkerBot O6 dexterous hands (bimanual)

Control Space: Joint space with absolute joint position targets

• Arms: in radians
• Hands: normalized [0, 1]

Action Vector Layout (26-DoF total):

Component	DoF	Description
Left Arm	7	shoulder_pitch, shoulder_roll, shoulder_yaw, elbow, wrist_roll, wrist_pitch, wrist_yaw
Right Arm	7	shoulder_pitch, shoulder_roll, shoulder_yaw, elbow, wrist_roll, wrist_pitch, wrist_yaw
Left Hand	6	thumb_bend, thumb_lateral, index, middle, ring, pinky (normalized 0-1)
Right Hand	6	thumb_bend, thumb_lateral, index, middle, ring, pinky (normalized 0-1)

Raw action vector ordering (indices 0-25):

[0:7]   - Left arm joint positions (rad)
[7:14]  - Right arm joint positions (rad)
[14:20] - Left hand joint positions (normalized 0-1)
[20:26] - Right hand joint positions (normalized 0-1)

In our G1 experiments, the waist, head, and lower body are fixed. We only control the arms and hands.

Unified Action Space: Being-H uses a 200-dimensional unified action space for cross-embodiment training. For G1, the 26 active dimensions are mapped to specific semantic slots:

• Right Arm → slots [50, 57)
• Left Arm → slots [57, 64)
• Right Hand → slots [20, 26)
• Left Hand → slots [32, 38)

The remaining dimensions are masked/zeroed during training and inference.

We will update the documentation with more details about how to set proper slots for custom embodiments. Feel free to reach out if you have further questions!

[CorneliaMelon]

Thanks! One follow-up to clarify the initialization detail for the Action Expert.

Given the architecture (shared attention, but separate FFN/MLP blocks per expert) and the fact that the Action Expert appears to follow a Qwen3-0.6B-sized configuration, I’m assuming the Action Expert is initialized from the pre-trained Qwen3-0.6B weights, not just the architecture.

Could you confirm what you actually do?

• Do you load pre-trained Qwen3-0.6B weights into the Action Expert (at least into the expert-specific FFN/MLP blocks and any other non-shared blocks)?
• Or do you use only the Qwen3-0.6B architecture and initialize those Action-Expert-only parameters randomly (with the Action Expert trained during your pretraining / post-training)?

Also, did you run an ablation comparing:

• Action Expert initialized from pretrained Qwen3-0.6B weights vs
• Action Expert initialized randomly (architecture-only)

I actually never ablated using the pretrained Qwen3-0.6B weights (only randomly initialized) in my MoT models (given I have other modalities apart from action prediction which I assumed would be too far OOD). If you could share this detail, it would be very helpful.

[zawnpn]

Thanks for the question!

We use random initialization for the Action Expert at the start of pretraining, not pretrained Qwen3-0.6B weights. Looking at our code (qwen3_navit.py):

def init_expert(self, expert_path, from_scratch=True):
    if from_scratch:
        print("INFO: `from_scratch=True`. Expert (`_mot_gen`) parameters will be randomly initialized.")
        return

However, if you're doing post-training using --resume_from with our released pretrained checkpoint, the Action Expert weights will be loaded from that checkpoint (via FSDPCheckpoint.try_load_ckpt), then you'll get our pretrained Action Expert weights, not random init.

[CorneliaMelon]

Thanks for clarifying! Quick question about the use_expert flag in the released code.

In BeingHConfig, there is a switch:

• use_expert=True: two-stream setup (packed_sequence_und in hidden_size + packed_sequence_gen in expert_config.hidden_size), with action/state routed through the gen stream and forward_train() returning both hidden_states_und and hidden_states_gen.
• use_expert=False: single-stream baseline where state/action are inserted into the main hidden_size sequence and action loss is computed from hidden_states_und (no gen stream).

Did you run any ablations comparing:

• use_expert=True vs
• use_expert=False (i.e., removing the separate action expert stream and collapsing everything into one stream)?

If yes:

• which benchmarks/tasks did you evaluate this on (sim + real robot)?
• what was the impact on performance and training stability?

If no:

• is use_expert=False intended as an unsupported/debug-only path, or a baseline you considered but didn’t include?

Also, did you do ablations with self.use_flow_matching=False?

[zawnpn]

Hi, use_expert and use_flow_matching are interfaces reserved for future exploration of more model architectures. Currently, we have only conducted ablation experiments on the main architecture presented in the paper. For more details, please refer to our paper.

[CorneliaMelon]

I see, thanks! Quick question about the real-robot dataset details.

You mention collecting 135.7 hours on the Unitree G1edu-u3. Could you clarify the task composition of those 135.7 hours (e.g., hours or % per task)?

Any details on environment diversity (different objects/packages, barcode positions, lighting/backgrounds) and whether the 135.7h includes human correction data or only “successful” trajectories would also be super helpful.

Thanks in advance!