G1-D — Wheeled Data-Collection Platform

0. WHAT THE G1-D IS (official page verified)

• Official name G1-D, unitree.com/G1-D, "End-to-End Platform for Humanoid Robot".

Announced 2025-11-13. Purpose = embodied-AI DATA-COLLECTION/training platform

(Service/Life/Retail/Industry scenarios) — NOT a delivery robot.

• Two variants: Standard = FIXED base (no wheels!), 17 DoF, 9 Ah quick-release

battery, ~2 h. Flagship = differential-drive AGV base ("360° in-place rotation",

1.5 m/s), 19 DoF, + built-in 30 Ah chassis battery, ~6 h; chassis lidar ×1 + depth cam ×2

"Ultimate".)

• G1 upper body on a lift column: 2× 7-DoF arms (~3 kg payload each, 0.45 m reach),

2-DoF waist (Z ±155°, Y −2.5..+135°), head HD binocular cam 3840×1200 115° + 2 wrist

cams 1920×1080 130°. **End-effector ecosystem = gripper / Dex3 (with or without tactile) / Revo2

5-finger, the same hands offered on the G1. Compute = an 8-core CPU as standard on both variants**, with a

high-compute module available as an option (Unitree names an Orin NX 16GB / 100 TOPS as one

example among multiple brands and models). See section 10 - the "ships with an Orin NX"

reading is wrong and had propagated widely; WiFi 6/BT 5.2. Lift column: 500 mm stroke, height 1260→1680 mm, ~60 mm/s.

• Ships with UnifoLM-WMA-0 (note: those weights are released under a

non-commercial licence) and claims integration with "PI and GROOT". Manual controller + visualization PC included; OTA.

• Mass: approximately 90 kg total, including battery, for BOTH variants — Unitree's

own spec table, re-read 2026-08-07. Press coverage citing ~80 kg, and reseller listings

citing 50 kg for the Standard, do not match the manufacturer. There is no published

base-only figure, so plan lifting and site access on 90 kg. The G1-D is not listed on

shop.unitree.com; it is a contact-sales product. South African pricing is on the G1-D

product page.

• DISAMBIGUATION TRAP: the viral Apr-2026 "wheeled G1 skating" videos = a LEGGED G1

with wheel-feet (research demo) — NOT the G1-D. Don't conflate.

1. SDK SURFACE (read from source — the ground truth)

• AgvClient (C++ ONLY — sdk2_python has ZERO g1d/agv code): service "agv"

v1.0.0.1, exactly TWO verbs:

(+CCW); vy documented "not supported for AGV, ignored" = DIFF-DRIVE confirmed.

Non-blocking JSON RPC.

column velocity = vz × 76.5 mm/s. NO position setpoint exists — official

g1d_height_control.cpp closes a DIY PD loop in user code (kP=20, kD=0.3, 50 ms,

|vz|≤0.8, tol 1 mm ×20 cycles, 500 ms feedback-timeout → HeightAdjust(0)).

or mode-switch verbs.**

• Height feedback: DDS topic rt/hispeed_state (ROS2 geometry_msgs Point32_;

.y = column height in METERS).

• AgvBmsState_ (idl/hg): software_version, battery_percentage(u8), current(i32),

temperature(i16[3]), docking_status(string), is_charging, is_dc_connected — dock

TELEMETRY exists but no dock command anywhere in the SDK, and **its DDS topic name

appears NOWHERE in the repo — discover on-robot** Not established. Not in python IDL either.

• Low-level = same hg contract: identical 29-slot LowCmd_/LowState_ on rt/lowcmd /

rt/lowstate / rt/secondary_imu, same CRC (0x04c11db7), mode_pr=0, mode_machine echo.

INVALID joints: 0-11 (legs) + 13 (WaistRoll). VALID: WaistYaw(12) + arms(15-28)

(Kp 60 waist / 40 arms, Kd 1). Index 14 (WaistPitch) AMBIGUOUS — source comments

inconsistent, URDF has a powered pitch fold — verify on-robot Not established. Gamepad still in

LowState.wireless_remote.

• Wheels + column are NOT in the motor array — no low-level wheel access at all; base

motion exists ONLY via the agv RPC.

• g1_d.urdf (unitree_ros/robots/g1_d_description, BSD-3): NO leg joints; AGV_link 37 kg;

wheels at y=±0.2031 (track 0.4062 m), 8 N·m/1.5 kg each; lift = 2 stacked 0.21 m

prismatic stages (0.42 m, 0.05 m/s each, effort 500); **misnamed Yaw_Joint is a

PITCH-axis torso fold** (−0.044..+2.356 rad, 80 N·m) + torso_Joint = waist yaw ±2.705;

standard 7-DoF arms + 7-DoF Dex3-style hands (rubber-hand meshes also shipped);

ZERO sensor links (no imu/lidar/camera frames — add your own); total 70.7 kg;

floating-base joint commented out.

• No sim assets anywhere — unitree_mujoco / rl_gym / rl_lab have zero g1d paths; the

URDF is the only official model.

2. NAVIGATION STACK BLUEPRINT (Flagship, greenfield — NO community G1-D stack exists)

Core loop: thin bridge node geometry_msgs/Twist → AgvClient.Move(vx, 0, vyaw) →

Nav2 with MPPI controller (DiffDrive motion model; "highly recommended" per Nav2

tuning guide, 50+ Hz on x86 — ARM/Jetson Hz undocumented, benchmark first; RPP =

cheaper fallback for exact aisle-following) → robot_localization EKF fusing

wheel-odom + IMU for odom→base_link [wheel odom source on G1-D = TBD on-robot Not established; no

odom topic found in SDK] → map→odom from lidar SLAM (chassis lidar model unknown Not established) or

AMCL → KeepoutFilter + SpeedFilter costmap masks for site zoning →

nav2_docking (in-tree since June 2024; ChargingDock plugin + staging pose + spiral

final approach) — G1-D gives dock TELEMETRY (AgvBmsState) but no dock command: the final

approach is ours to drive via Move() Not established.

Perception: isaac_ros_nvblox outputs Nav2 costmaps BUT current release = ROS2 Jazzy +

Jetson Thor required; Orin-class = older Humble-era Isaac ROS (the a related reference "pin 3.2" law

again) or ethz-mrl/nvblox_ros2 (no Isaac deps). D435i-class depth → spatio_temporal_voxel_layer

(a related reference §7) works today on Humble.

Whole-body (arms+base): MoveIt2 planar virtual joint w/ diff_drive motion model

(official tutorial) for short coordinated motions; long-range = Nav2. Closest wheeled-

humanoid analog = GalaxeaVLA (R1 Pro WBC incl. torso, 27-dim action) — the config

pattern to copy for learning-based control. GR00T has NO wheeled/G1-D embodiment —

the path is a NEW_EMBODIMENT post-train on teleop data you collect yourself (vx/vyaw + arms).

Fleet layer (if client sites want it): VDA 5050 (v3.0.0 Mar-2026 — check connector

spec versions): inorbit-ai/ros_amr_interop (ROS2, humble-devel), Fraunhofer libVDA5050++,

NVIDIA isaac_mission_dispatch. Doors/elevators = Open-RMF door/lift adapter templates.

ROS distro skew warning: several candidate pieces target Jazzy (nvblox current,

ETH sru-robot-deployment) while much tooling is still on Humble — pin branches per component.

Wheeled quadruped cousins: GO2-W (jj7258/unitree_go2w_ros2 driver, Apache; UPenn

go2w_agent_sdk Nav2+Faster-LIO but Noetic/Foxy-bridged + mixed licenses), B2-W (ETH

sru-robot-deployment, MIT, learned nav, Jazzy).

3. WHAT THIS PLATFORM CHANGES

1. Same wire protocol, no balance problem: hg DDS and arm joint indices 15-28 mean G1

application code ports across with the legs removed. Because the platform is statically

stable, the whole-body balance safety layer a legged humanoid needs is simply not in play

for base motion; a hard stop is Move(0,0,0) plus a velocity timeout.

1. Data collection: the G1-D is Unitree's own data rig for the UnifoLM and LeRobot

pipelines. Teleoperating the arms while the base is parked yields clean manipulation

episodes with none of the noise a balancing biped injects.

1. End effectors: the official list includes the tactile Dex3 and the Revo2, so the same

hands offered on the G1 mount here unchanged.

1. Indoor patrol: the wheeled variant gives roughly 6 hours of endurance with none of the

fall risk of a biped. Duty cycle and thermal behaviour should be measured on the unit.

4. COMMISSIONING CHECKLIST

ros2/DDS topic dump → find AgvBmsState topic name + wheel-odom source · confirm joint 14

(WaistPitch) validity · chassis lidar model + topic · scale/verify weight (90 vs 50 kg

Standard conflict) · Move() latency + velocity-timeout behavior (is there a deadman?) ·

height PD loop tune on real column · dock telemetry semantics (docking_status strings).

9. Corrections, and how they were found

The specification below was read directly from Unitree's own English product page on

7 August 2026, in full rather than sampled. An earlier partial reading of the same page

produced two wrong figures that circulated widely, so the corrections are set out explicitly.

Unitree's own column labels are G1-D (Standard) and G1-D (Flagship). The Flagship is

the variant sold as "Ultimate".

What this corrects

• The G1-D does not ship with a Jetson Orin NX 16GB. The baseline on both variants is an

8-core CPU. Orin NX 16GB is one named example of an optional high-compute module, and Unitree

states that multiple brands and models are available, so even "the optional module is an Orin

NX" overstates the position. This one is worth being careful about: the Orin figure appears in

a great deal of secondary coverage of this robot.

• Column travel is 420 mm, not 500 mm. The overall height runs 1260 mm to 1680 mm, a

difference of 420 mm. The widely repeated 500 mm figure is inconsistent with Unitree's own

height range.

• Total mass is approximately 90 kg for both variants, including battery. Press coverage

citing ~80 kg, and reseller listings citing 50 kg for the Standard, do not match the

manufacturer. Unitree publishes no base-only mass, so plan lifting and site access on 90 kg.

• Battery, stated precisely: the Standard column lists a 9 Ah quick-release upper-body

battery and about 2 hours; the Flagship column lists a 30 Ah built-in chassis battery and

about 6 hours. The Flagship very likely also carries the upper-body pack, since it is the same

upper body, but Unitree does not print it, so it is not asserted here.

• The announcement date is not established. The November 2025 date in circulation is the

publication date of an article about the robot, not a stated unveiling date.

Still confirmed on re-reading: the G1-D is positioned as an end-to-end embodied-AI data

collection and training platform, not a logistics or delivery robot, and the Standard base is

non-driven.

On method: these errors were caught by a second pass whose job was to refute the first, not

to agree with it. On product specifications one reading is not verification, and a partial

reading is how the compute error survived in the first place.