Unitree G1 Developer Guide: SDK, ROS 2, Simulation and Your First Research Project
Industry News

Unitree G1 Developer Guide: SDK, ROS 2, Simulation and Your First Research Project

2026 Research Guide · Official Unitree Sources Checked

Unitree G1 Developer Guide: SDK, ROS 2, Simulation and Your First Research Project

Understand the real G1 development stack—from Unitree SDK2 and Cyclone DDS to ROS 2, MuJoCo, Isaac Lab and sim-to-real validation—then complete a safe, useful first humanoid-robotics project without beginning with uncontrolled motion.

G1 Basic vs EDU SDK2 C++ & Python ROS 2 & DDS MuJoCo & Isaac Lab First research project
Unitree G1 humanoid robot used for SDK, ROS 2 and simulation research
UNITREE SDK2 CYCLONE DDS ROS 2 MUJOCO ISAAC LAB SIM → REAL
Quick answer

For serious G1 development, start with a confirmed G1 EDU configuration, build the communication layer with SDK2 and Cyclone DDS, use ROS 2 when your research needs ROS nodes and tooling, validate low-level control in MuJoCo, and use Isaac Lab or Unitree’s RL projects only after the basic data, model and safety pipeline works.

Correct development model: G1 EDU
Core middleware: Cyclone DDS
G1 message family: unitree_hg
Best first project: Read-only telemetry
Navigate this guide
Development starts before installation

Choose the correct G1 hardware before writing code

Unitree’s public G1 comparison lists secondary development for G1 EDU and does not list it for standard G1. The two robots share the same general body dimensions and base sensing concept, but they are not interchangeable when SDK access, additional computing, expanded joints or dexterous hands are contractual research requirements.

On smaller screens, swipe the table left to compare standard G1, configurable G1 EDU and the current SpeedyDrone U2 listing.

Unitree G1 Basic, configurable G1 EDU and SpeedyDrone G1 EDU U2 comparison for developers
Development requirement G1 Basic G1 EDU official range SpeedyDrone G1 EDU U2 listing
Secondary development Not listed by Unitree Supported Development-oriented configuration
Total degrees of freedom 23 23–43, configuration-dependent 29
Waist / arm profile 1 waist DoF; 5 DoF per arm Optional extra waist and wrist joints 3 waist DoF; 7 DoF per arm
High-computing module Not listed Multiple options, including Orin-class modules Listed 100-TOPS computing configuration
Dexterous hands Not listed in official comparison Optional; exact model and sensors vary Often not included; confirm separately
Depth camera + 3D LiDAR Listed Listed Listed
Official warranty period 8 months 18 months Confirm final quotation and applicable terms
Current SpeedyDrone price* CAD $25,699 Configuration quote CAD $76,980
Best fit Platform evaluation and supported demonstrations University research, SDK work and custom integration 29-DoF research with higher onboard compute

*Prices were checked July 21, 2026 and may change. “G1 EDU U2” is a channel configuration name, not the complete Unitree EDU family. Confirm joint count, compute, controller, hands, sensors, charger, firmware access, SDK entitlement, warranty and delivery package before purchase.

Procurement rule: do not write “Unitree G1 for research” in a purchase order and assume the development package is understood. Name the exact EDU configuration, compute, degrees of freedom, hand model, software access and acceptance tests.

Understand the system boundary

The Unitree G1 development architecture in one view

G1 development is not a single “ROS driver.” A practical system separates your research workstation, DDS communication, optional development computing, Unitree’s protected control environment and the physical robot. This separation matters for reliability, debugging and safety.

PC

Research workstation

Source code, ROS 2 nodes, logging, visualization, model training and experiment management.

DDS

Cyclone DDS

Transport layer used by SDK2 and compatible ROS 2 message communication.

DEV

Development compute

User applications, perception, AI workloads and optional higher-compute modules on EDU configurations.

CTRL

Control compute

Unitree motion-control services and protected platform functions. Do not treat it as a general workstation.

G1

Robot hardware

Joint motors, encoders, IMUs, depth camera, 3D LiDAR, audio, battery and optional hands.

Control plane

Keep platform control stable

Unitree’s motion-control environment should remain distinct from experimental user workloads. A research process should know which services must remain active and which interfaces are intended for development.

Data plane

Define the messages you actually need

G1 low-level communication uses the unitree_hg message family. Typical research begins with state messages such as joint feedback and IMU data before any command publication.

Safety plane

Keep human override outside your experiment

Remote control, stop procedures, physical support, test-zone control and recovery plans should remain available even when the research node, network or learned policy fails.

Best-practice starting point: build a read-only data path first. Prove that the workstation can discover, timestamp, record and validate robot state before enabling command topics.

Use the right tool for the right layer

SDK2, ROS 2, MuJoCo and Isaac Lab are complementary—not interchangeable

unitree_sdk2

Official C++ communication and control SDK

Use SDK2 when you want Unitree’s native C++ interfaces, direct DDS communication and the clearest alignment with official examples. The repository lists Ubuntu 20.04 LTS, x86_64 or aarch64 and GCC 9.4.

  • Best for production-oriented C++ nodes
  • CMake-based integration
  • Official examples and message types
unitree_sdk2_python

Fast prototyping and experiment scripts

The Python interface is useful for telemetry, rapid experiments and research tooling. It still relies on correct Cyclone DDS setup and should not be treated as a shortcut around robot safety.

  • Fastest path for read-only prototypes
  • Useful for data collection and orchestration
  • Confirm API changes against the current release
unitree_ros2

ROS 2 messages over Cyclone DDS

ROS 2 can communicate using Unitree’s DDS-compatible messages. For G1, inspect the current unitree_hg package and G1 examples rather than assuming every Go2 or H1 example is drop-in compatible.

  • Humble is the repository’s recommended tested ROS 2 path
  • Useful for rosbag, RViz, composition and research ecosystems
  • Version-pin message definitions
unitree_mujoco

Low-level controller validation

Unitree’s MuJoCo simulator integrates with SDK2, ROS 2 and SDK2 Python. The current repository emphasizes low-level messages and sim-to-real verification rather than complete emulation of every built-in high-level G1 service.

  • C++ simulator is recommended by the repository
  • Python simulator supports rapid testing
  • Use a separate DDS domain from the physical robot
unitree_rl_lab

Isaac Lab reinforcement learning

Unitree RL Lab provides Isaac Lab environments and currently lists support for the G1 29-DoF model. It is appropriate for large-scale RL experiments when the research team can manage GPU, simulator and version complexity.

  • G1 29-DoF support is explicitly listed
  • Suitable for vectorized training
  • Requires careful Isaac Sim / Isaac Lab version matching
unitree_rl_mjlab

MuJoCo-based RL and sim-to-real

Unitree RL Mjlab uses MuJoCo as the physics backend and lists G1 support. Its published workflow is Train → Play → Sim2Real, making it a lighter alternative for some research programs.

  • MuJoCo physics backend
  • Modular RL research workflow
  • Still requires hardware-specific validation

Recommended progression: SDK2 or ROS 2 telemetry → MuJoCo low-level verification → controlled hardware observation → simple commanded motion → only then reinforcement learning or imitation learning.

Make the environment reproducible

Plan the workstation, operating system and repository versions

SDK2 baseline
Ubuntu 20.04

Unitree SDK2’s repository lists Ubuntu 20.04 LTS, GCC 9.4, CMake 3.10+ and x86_64 or aarch64 as its prebuild environment.

ROS 2 baseline
Humble

Unitree’s ROS 2 repository lists Ubuntu 22.04 with ROS 2 Humble as recommended and Ubuntu 20.04 with Foxy as tested.

Research baseline
Version lock

Record the operating system, compiler, ROS distribution, repository commit, robot firmware, message definitions and model configuration for every experiment.

A robotics lab should avoid one untracked workstation that everyone modifies. Create a documented development image or container for each stack and keep the robot-facing environment conservative. Simulation and RL stacks can use separate machines because their dependency requirements evolve more quickly.

  • One robot-facing Linux workstation with a dedicated Ethernet interface
  • One reproducible SDK2 / ROS 2 environment
  • Separate simulation environment for MuJoCo
  • GPU workstation for Isaac Lab when required
  • Git commit hashes recorded in every experiment
  • Offline copy of known-good repositories and dependencies
  • Change log for firmware, models, hands and joint configuration
Official Unitree G1 component diagram for developer planning
Official Unitree G1 component illustration. Compute, hands and other elements are configuration-dependent.

Do not assume the newest operating system is the easiest path. Robotics dependencies frequently lag desktop Linux releases. Use the combinations tested by the current official repository or a validated container, then upgrade deliberately rather than during a live robot experiment.

Communication is part of the experiment

Configure the G1 network and Cyclone DDS deliberately

Unitree SDK2 uses Cyclone DDS. ROS 2 also uses DDS, which allows compatible message types to communicate directly. Correct interface selection, DDS domain separation and static network configuration are therefore foundational—not troubleshooting details.

Physical robot network

Use a dedicated wired interface

Unitree’s general ROS 2 instructions use a workstation address such as 192.168.123.99/24. G1 documentation identifies the development board at 192.168.123.164 in relevant configurations.

Simulation network

Use loopback and a separate domain

Unitree MuJoCo recommends the local loopback interface lo for simulation and a DDS domain such as 1, distinct from the physical robot’s default domain.

Lab security

Keep robot control isolated

Do not bridge the initial control network directly to public Wi-Fi or the broader enterprise network. Add routing, remote access and cloud services only after review and logging.

robot-network.sh
# Example only: replace enp3s0 with the actual wired interface.
# Confirm the current Unitree documentation for the delivered configuration.

ip link show
sudo ip addr flush dev enp3s0
sudo ip addr add 192.168.123.99/24 dev enp3s0
sudo ip link set enp3s0 up

source /opt/ros/humble/setup.bash
source "$HOME/unitree_ros2/cyclonedds_ws/install/setup.bash"
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
export CYCLONEDDS_URI='<CycloneDDS><Domain><General><Interfaces>
  <NetworkInterface name="enp3s0" priority="default" multicast="default" />
</Interfaces></General></Domain></CycloneDDS>'

ros2 topic list

Never test simulation and hardware on an ambiguous DDS configuration. Use a different domain ID and interface for simulation, confirm the active interface before launching a publisher, and stop immediately if physical robot topics appear in the simulation workspace unexpectedly.

Build the native foundation

Install Unitree SDK2 before adding unnecessary complexity

SDK2 is the clearest starting point for understanding Unitree’s communication model. Build the official examples, verify a read-only state subscriber and preserve the exact repository commit before integrating ROS 2, perception or learned policies.

install-unitree-sdk2.sh
sudo apt update
sudo apt install -y \
  cmake \
  g++ \
  build-essential \
  libyaml-cpp-dev \
  libeigen3-dev \
  libboost-all-dev \
  libspdlog-dev \
  libfmt-dev

git clone https://github.com/unitreerobotics/unitree_sdk2.git
cd unitree_sdk2

git rev-parse HEAD

mkdir -p build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/opt/unitree_robotics
make -j"$(nproc)"
sudo make install
Step 1

Build without the robot

Prove that dependencies, headers, message definitions and examples compile before connecting to the G1 network.

Step 2

Identify the G1 message family

G1 and H1-2 low-level communication use unitree_hg. Examples built around unitree_go require adaptation rather than simple renaming.

Step 3

Subscribe before publishing

Begin with state messages such as rt/lowstate. Verify timestamps, joint count, IMU fields and data rate before sending commands.

Repository discipline: record the SDK2 commit in the lab notebook and in the generated dataset metadata. A later message-definition change can otherwise make old bags, Python scripts or analysis notebooks difficult to reproduce.

ROS 2 is an ecosystem layer

How ROS 2 fits into Unitree G1 development

ROS 2 is valuable when the project needs rosbag recording, node composition, visualization, lifecycle management, perception packages or multi-sensor integration. It does not replace understanding SDK2, DDS domains and the robot’s message definitions.

Use ROS 2 when

Your project is a system of nodes

  • You need rosbag2 datasets
  • You want RViz, TF or standard visualization tools
  • You are integrating cameras, LiDAR or external sensors
  • You need modular perception, planning or logging nodes
  • Your research team already uses ROS 2 conventions
Stay closer to SDK2 when

The experiment is small and timing-sensitive

  • You need a focused C++ control process
  • You are adapting official SDK examples
  • You want minimal middleware abstraction
  • You are debugging DDS or message-level behaviour
  • You do not need the broader ROS ecosystem
unitree-ros2-humble.sh
# Install ROS 2 Humble separately using the official ROS documentation.
# Then install Unitree's listed ROS 2 dependencies.

sudo apt install -y \
  ros-humble-rmw-cyclonedds-cpp \
  ros-humble-rosidl-generator-dds-idl \
  libyaml-cpp-dev

git clone https://github.com/unitreerobotics/unitree_ros2.git
cd unitree_ros2/cyclonedds_ws

source /opt/ros/humble/setup.bash
colcon build --symlink-install
source install/setup.bash

ros2 interface list | grep unitree_hg
ros2 interface show unitree_hg/msg/LowState

Documentation nuance: the main unitree_ros2 README historically names Go2, B2 and H1, while the current repository includes unitree_hg messages and G1-related changes. Use Unitree’s G1-specific document pages and current repository contents together; do not infer G1 support from an older generic example alone.

Simulation is a risk-reduction tool

Choose the right G1 simulation path

“Simulation” can mean model visualization, low-level controller verification, large-scale RL training or imitation learning. Choose the environment based on the research question rather than selecting the most visually impressive simulator.

On smaller screens, swipe the table left to compare G1 simulation paths.

Unitree G1 MuJoCo, Isaac Lab and reinforcement-learning simulation comparison
Tool Best use G1 support position Main caution
unitree_mujoco Low-level SDK2 controller and message verification Includes G1 model and unitree_hg communication path Current scope emphasizes low-level development, not all high-level services
unitree_rl_lab Large-scale reinforcement learning in Isaac Lab Official repository lists G1 29-DoF support Isaac Sim, Isaac Lab, Python and GPU versions must match
unitree_rl_mjlab MuJoCo-based RL and sim-to-real research Official repository lists G1 support Learned policies still require staged physical validation
unitree_rl_gym Isaac Gym training with sim2sim and sim2real workflow Official repository lists G1 Treat as a version-sensitive research stack, not a turnkey deployment package
Generic URDF / visualization Geometry, TF, collision and visualization Useful for planning and software integration Visualization alone does not validate dynamics or hardware control
simulate/config.yaml
# Example simulation separation pattern.
# Check the current repository because file names and defaults may change.

robot: "g1"
robot_scene: "scene.xml"
domain_id: 1
interface: "lo"
print_scene_information: 1

# Keep simulation isolated from the physical robot's DDS domain.
# G1 low-level messages use the unitree_hg IDL family.
MuJoCo first

Best for basic controller plumbing

Verify joint indexing, state messages, timing, controller output limits and failure behaviour before any hardware publisher is enabled.

Isaac Lab later

Best for scalable RL

Use Isaac Lab after the robot model, observation space, action space, reward design and deployment interface are already understood.

Sim2sim before sim2real

Detect simulator dependence

Testing a policy in a second simulator can expose overfitting to one physics engine before the robot carries the risk.

Simulation is not a safety certificate. Unmodelled latency, actuator limits, contact behaviour, battery voltage, joint friction, payloads, calibration and floor conditions can destabilize a policy that looks reliable on screen.

Your first research project

Build a G1 posture and stability telemetry pipeline

The best first project is useful, publishable and low risk. Instead of commanding walking or training a policy immediately, build a read-only pipeline that records joint and IMU state in simulation and on the physical G1, then measures whether the two data sources are consistent enough for later control research.

Research question

Can one telemetry pipeline describe G1 posture consistently in simulation and hardware?

Collect synchronized joint position, joint velocity and torso IMU data during defined static or supported poses. Compare message structure, rate, drift, missing samples and signal ranges across simulation and the physical robot.

  • No learned policy required
  • No low-level command publisher required
  • Produces a reusable dataset and data dictionary
  • Validates ROS 2, DDS and model configuration
  • Creates a foundation for balance or anomaly research
1

Lock the configuration

Record whether the robot is 23, 29 or another EDU joint configuration. Export the joint map and confirm message definitions.

2

Record simulation

Use domain 1 and loopback. Record rt/lowstate and the G1 secondary IMU topic while the model is supported and stationary.

3

Validate the dataset

Check message rate, timestamps, joint count, missing fields, signal range and consistency before moving to hardware.

4

Repeat on hardware

With trained staff, physical support and no command publisher, collect the same short observation protocol on the real robot.

Step 1: inspect the current G1 message definition

inspect-g1-messages.sh
source /opt/ros/humble/setup.bash
source "$HOME/unitree_ros2/cyclonedds_ws/install/setup.bash"
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

ros2 interface show unitree_hg/msg/LowState
ros2 topic list | grep -E 'lowstate|secondary_imu'
ros2 topic info /rt/lowstate --verbose
ros2 topic hz /rt/lowstate

Step 2: record a short simulation dataset

record-g1-telemetry.sh
# In the simulation environment, use loopback and a non-hardware DDS domain.
source "$HOME/unitree_ros2/setup_local.sh"
export ROS_DOMAIN_ID=1

mkdir -p "$HOME/g1_research/bags"
cd "$HOME/g1_research/bags"

ros2 bag record \
  /rt/lowstate \
  /rt/secondary_imu \
  --output g1_static_pose_sim_01

Topic availability can vary by repository release and configuration. Confirm with ros2 topic list before recording. Unitree MuJoCo documents rt/secondary_imu as a G1 torso IMU topic in its supported-message description.

Step 3: create a read-only CSV logger

g1_telemetry_logger.py
#!/usr/bin/env python3
"""Read-only Unitree G1 telemetry logger.

Verify the current unitree_hg LowState definition before use.
This node subscribes only; it does not publish robot commands.
"""

import csv
from pathlib import Path

import rclpy
from rclpy.node import Node
from unitree_hg.msg import LowState


class G1TelemetryLogger(Node):
    def __init__(self) -> None:
        super().__init__("g1_telemetry_logger")
        output = Path.home() / "g1_research" / "g1_lowstate.csv"
        output.parent.mkdir(parents=True, exist_ok=True)

        self._file = output.open("w", newline="", encoding="utf-8")
        self._writer = csv.writer(self._file)
        self._header_written = False

        self.create_subscription(
            LowState,
            "/rt/lowstate",
            self._on_state,
            10,
        )
        self.get_logger().info(f"Logging read-only state to {output}")

    def _on_state(self, msg: LowState) -> None:
        motor_positions = [float(motor.q) for motor in msg.motor_state]
        motor_velocities = [float(motor.dq) for motor in msg.motor_state]
        rpy = [float(value) for value in msg.imu_state.rpy]

        if not self._header_written:
            header = ["ros_time_ns", "roll", "pitch", "yaw"]
            header += [f"q_{index}" for index in range(len(motor_positions))]
            header += [f"dq_{index}" for index in range(len(motor_velocities))]
            self._writer.writerow(header)
            self._header_written = True

        timestamp = self.get_clock().now().nanoseconds
        self._writer.writerow([timestamp, *rpy, *motor_positions, *motor_velocities])
        self._file.flush()

    def destroy_node(self) -> bool:
        self._file.close()
        return super().destroy_node()


def main() -> None:
    rclpy.init()
    node = G1TelemetryLogger()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        rclpy.shutdown()


if __name__ == "__main__":
    main()

The example assumes the generated ROS 2 Python message exposes motor_state, motor q and dq, plus IMU rpy. Confirm the exact current interface with ros2 interface show and adjust if the repository release differs.

Step 4: define the analysis before collecting hardware data

Signal integrity

Measure the data path

  • Observed message rate
  • Timestamp monotonicity
  • Dropped or duplicate samples
  • Expected joint count
  • NaN or out-of-range values
Posture features

Create simple interpretable metrics

  • Mean roll and pitch
  • Roll and pitch RMS
  • Joint-position variance
  • Joint-velocity noise floor
  • Pose-to-pose repeatability
Research metadata

Make the result reproducible

  • Robot model and joint configuration
  • Firmware and repository commits
  • DDS domain and network interface
  • Floor, support and pose description
  • Operator and test timestamp

Publishable outcome: the project can produce a short methods report, a versioned G1 telemetry dataset, a simulation-versus-hardware comparison and a validated data pipeline for later balance, anomaly-detection or control work.

Do not jump from a graph to a moving humanoid

Use explicit gates before sim-to-real deployment

Sim-to-real should be a sequence of approvals, not one launch command. Each gate should have evidence, an owner and a stop condition. The higher the robot energy and motion complexity, the stronger the gate must be.

GATE 01 · MODEL

Joint count, motor IDs, limits, coordinate frames and inertial model match the delivered G1 configuration.

GATE 02 · SOFTWARE

Repository commits, dependencies, message types and command limits are locked and reproducible.

GATE 03 · SIMULATION

The controller remains stable across disturbances, delays, parameter variation and a second simulator when appropriate.

GATE 04 · SUPPORTED TEST

The physical robot is restrained or supported, the area is controlled and only low-energy motion is enabled.

GATE 05 · FREE MOTION

Low-speed operation begins only after the stop procedure, operator roles and recovery plan are verified.

Domain randomization

Vary the assumptions

Test mass, friction, delay, actuator strength, sensor noise and contact conditions instead of training against one perfect model.

Command limits

Constrain energy before intelligence

Bound target position, velocity, torque, rate of change and experiment duration outside the learned policy or planner.

Fallback state

Define failure behaviour

Communications loss, invalid observations, stale commands and software exceptions need deterministic safe responses.

Unitree’s own warning matters: the G1 is a powerful humanoid with a complex structure. Maintain sufficient distance, avoid hazardous modification and use trained supervision during development.

Move beyond “it runs”

Design experiments that survive peer review and procurement review

Hypothesis

State what should change

Define the expected relationship between algorithm, observation, environment and measured outcome before collecting data.

Baseline

Compare against something credible

Use a fixed controller, no-policy condition, previous algorithm or supported Unitree behaviour as a clearly documented baseline.

Metrics

Measure success and failure

Track task success, intervention rate, falls, energy use, latency, tracking error and recovery—not only average reward.

Protocol

Repeat the same test

Define start pose, floor, payload, command sequence, number of trials, stop condition and exclusion rules.

Traceability

Link every result to software

Store code commit, model checkpoint, configuration, firmware, calibration and dataset identifiers with each run.

Negative results

Document where it breaks

Failure boundaries often provide more deployment value than a polished demonstration under one ideal condition.

Research roadmap

What to build after the first telemetry project

Project 02

Joint-state anomaly detection

Learn the normal relationship between joint position, velocity and IMU state during known poses, then flag unusual drift or vibration.

Project 03

Pose repeatability benchmark

Measure how consistently supported or built-in poses reproduce joint and torso state across batteries, temperatures and test days.

Project 04

External perception fusion

Add motion capture or an external camera and compare independent pose estimates with G1 onboard state under controlled motion.

Project 05

Low-energy arm trajectory study

After supported validation, compare trajectory smoothness, endpoint repeatability and current or torque estimates within conservative limits.

Project 06

Sim-to-real locomotion policy

Use Unitree RL Lab, RL Mjlab or RL Gym only after the joint map, observation pipeline, controller interface and hardware gates are validated.

Project 07

Dexterous-hand dataset

For a confirmed hand package, collect synchronized hand state, tactile data, object pose and task outcome for grasp research.

Project 08

Human-robot interaction study

Evaluate distance, motion predictability, audio cues and participant comfort under ethics, privacy and controlled-area approval.

Project 09

Energy-aware task planning

Model battery use against posture, movement duration, compute load and task completion to support realistic deployment planning.

Project 10

Reproducible humanoid benchmark

Create a documented test suite that another lab can reproduce using the same G1 configuration, messages, metrics and safety rules.

Common failure patterns

Why G1 development environments fail—and how to diagnose them

No topics visible

Check interface and DDS first

Confirm the wired NIC, IP subnet, Cyclone DDS interface, ROS domain, sourced workspace and whether the robot or simulator is actually publishing.

Messages do not build

Check package and release alignment

G1 uses unitree_hg. A stale workspace or mismatched SDK2 and ROS 2 message definitions can break compilation or deserialization.

Simulation works, robot does not

Compare assumptions systematically

Review motor IDs, joint configuration, command topic, DDS domain, built-in service state, calibration, limits and model version.

ROS 2 conflicts

Separate environments

Multiple sourced ROS distributions, local Cyclone DDS builds and stale overlays can create difficult-to-see runtime conflicts.

RL repository errors

Pin the simulator stack

Isaac Sim, Isaac Lab, Python, GPU drivers and the Unitree repository evolve independently. Reproduce an official tested combination before modifying tasks.

Unexpected motion

Treat it as a system failure

Stop, isolate publishers, recover the robot safely and preserve logs. Do not repeatedly rerun the command until the cause is understood.

Debugging order: model → network → DDS → message type → subscriber → logger → simulator → command interface. Changing all layers at once makes successful results difficult to reproduce and unsafe failures difficult to explain.

Institutional deployment

Laboratory safety, cybersecurity and research governance

Physical safety

Design for a fall

Use a clear zone, operator, spotter, physical support when appropriate, low-energy tests and a recovery procedure that avoids active joints.

Network security

Segment robot control

Keep the control network isolated, document remote-access paths, restrict credentials and log software or model changes.

Data governance

Protect camera and microphone data

Establish consent, access, storage, retention and deletion rules before recording identifiable people or sensitive spaces.

Human participants

Use institutional review

Human-robot interaction studies may require ethics, privacy, accessibility and safety approvals before recruitment begins.

Model governance

Know what policy is running

Record model provenance, training data, checkpoint hash, observation normalization, command limits and rollback method.

Operating authority

Define who can enable motion

Limit hardware command access to trained personnel and separate code review from permission to run on the physical robot.

Canadian ownership planning

Budget for a research program—not only a humanoid robot

CAD $25,699 SpeedyDrone G1 Basic listing checked July 21, 2026
CAD $76,980 SpeedyDrone G1 EDU U2 listing checked July 21, 2026
GPU / compute Simulation, training, storage and optional onboard compute
Research labour Integration, safety, data engineering, software and maintenance
Hardware

Specify the complete platform

  • Exact G1 EDU configuration
  • Compute module
  • Hands and tactile sensors
  • Batteries, charger and controller
  • Replacement and wear components
Infrastructure

Build the lab around the robot

  • Linux workstation and wired network
  • GPU training workstation when required
  • Test area and support equipment
  • Data storage and backup
  • Versioned development environments
Operations

Fund the full lifecycle

  • Operator and developer training
  • Commissioning and acceptance tests
  • Software maintenance
  • Warranty and service logistics
  • Insurance and institutional administration

Capital discipline: define the first three publishable or commercially useful milestones before buying optional hardware. A clear telemetry, simulation and safety plan creates more research value than an expensive configuration with no validated experiment pipeline.

SpeedyDrone Canada · Toronto

Configure the G1 research platform before you place the order

SpeedyDrone Canada supports universities, colleges, robotics laboratories, innovation teams and institutional buyers evaluating Unitree G1 and G1 EDU. Send your intended research, joint configuration, SDK requirement, compute workload, hand requirement, simulation stack, budget and target timeline for a configuration and deployment assessment.

G1 systems are special-order, configuration-sensitive products. Confirm software access, hardware version, compute, hands, sensors, package contents, warranty, lead time and commissioning requirements before purchase.

Frequently asked questions

Unitree G1 SDK, ROS 2 and simulation FAQ

Does Unitree G1 Basic support secondary development?

Unitree’s official G1 comparison does not list secondary development for standard G1. It lists secondary development for G1 EDU. Buyers who need SDK access or custom integration should specify a confirmed G1 EDU configuration in writing.

What is Unitree SDK2?

Unitree SDK2 is Unitree’s official version-two robot SDK for DDS-based communication and control. The repository provides C++ libraries, message definitions, examples and CMake integration guidance.

Can I develop for Unitree G1 with Python?

Yes. Unitree maintains the unitree_sdk2_python repository. Python is useful for telemetry, data collection, orchestration and rapid research prototypes, provided the correct Cyclone DDS environment and G1 message types are used.

Does Unitree G1 use ROS 2?

G1 communication is based on Unitree SDK2 and Cyclone DDS. ROS 2 also uses DDS, allowing compatible Unitree message types to be used in ROS 2 workflows. G1 low-level messages use the unitree_hg family.

Which ROS 2 distribution should I use for Unitree?

Unitree’s current unitree_ros2 repository lists Ubuntu 22.04 with ROS 2 Humble as recommended and Ubuntu 20.04 with Foxy as tested. Confirm the repository’s current requirements and keep the environment version-pinned.

What is the difference between unitree_go and unitree_hg messages?

Unitree’s simulator documentation states that Go2, B2 and several related platforms use the unitree_go IDL family, while G1 and H1-2 use unitree_hg for low-level communication. Examples must use the correct robot message family.

Can Unitree MuJoCo simulate the G1?

Yes. Unitree’s MuJoCo repository includes G1 model support and unitree_hg communication. Its current documented scope emphasizes low-level messages and sim-to-real controller verification rather than complete reproduction of every built-in high-level robot service.

Should I use MuJoCo or Isaac Lab for G1 research?

Use Unitree MuJoCo for lower-level controller and SDK communication validation. Use Isaac Lab when the project needs large-scale reinforcement-learning training and the team can manage the GPU and version requirements. Many programs use both.

Does Unitree RL Lab support every G1 configuration?

The official unitree_rl_lab repository currently lists G1 29-DoF support. Do not assume a 23-DoF or other configuration can use the same task, motor map or policy without adaptation and validation.

What should my first Unitree G1 research project be?

A read-only posture and stability telemetry project is an excellent start. Record joint and IMU state in simulation, validate the dataset, then repeat a controlled observation protocol on the physical robot without publishing motion commands.

What DDS domain should I use for simulation?

Unitree MuJoCo recommends separating simulation from the physical robot’s default domain. A domain such as 1 with the loopback interface is a common simulation pattern, but confirm the active configuration before launching any publisher.

Why can I not see G1 ROS 2 topics?

Common causes include the wrong wired interface, incorrect subnet, unsourced workspace, wrong ROS domain, Cyclone DDS not selected, stale message definitions or the robot/simulator not publishing the expected service.

Can a policy trained in simulation be deployed directly to G1?

It should not be deployed without staged validation. Use model checks, sim2sim testing, command limits, supported physical testing, trained operators, a controlled area and a verified stop procedure before free motion.

How much does a Unitree G1 research platform cost in Canada?

On July 21, 2026, SpeedyDrone listed G1 Basic at CAD $25,699 and G1 EDU U2 at CAD $76,980. A complete research budget may also include computing, hands, batteries, training, integration, safety equipment and software labour.

Where can a Canadian university request a Unitree G1 EDU quote?

Canadian universities and research organizations can contact SpeedyDrone Canada for configuration guidance, Toronto evaluation options, special-order pricing, financing questions and deployment planning.

Official and Canadian sources consulted
  1. Unitree G1 official product page and G1 versus G1 EDU comparison
  2. Unitree G1 official developer guide
  3. Unitree G1 quick-development guidance
  4. Unitree G1 startup and debug-mode guidance
  5. Unitree G1 basic service and low-level communication interface
  6. Unitree G1 DDS service and topic reference
  7. Unitree G1 ROS 2 communication routine
  8. Unitree SDK2 official GitHub repository
  9. Unitree SDK2 Python official GitHub repository
  10. Unitree ROS 2 official GitHub repository
  11. Unitree MuJoCo official simulator repository
  12. Unitree RL Lab official Isaac Lab repository
  13. Unitree RL Mjlab official MuJoCo reinforcement-learning repository
  14. Unitree RL Gym official reinforcement-learning repository
  15. SpeedyDrone Canada Unitree G1 collection
  16. SpeedyDrone Canada G1 Basic product listing
  17. SpeedyDrone Canada G1 EDU U2 product listing

Information and Canadian prices were checked July 21, 2026. Repositories, documentation, message definitions, firmware, simulation support, joint configurations, compute modules, hands, package contents, prices and warranty procedures can change. Examples in this article are educational starting points and must be verified against the exact delivered robot and current official documentation. Unitree warns that humanoid robots are powerful and complex, asks users to maintain sufficient distance and advises against hazardous modification or use.

Previous
Best Surveying Drones in Canada: Matrice 4E, Matrice 4D, Matrice 400, P1, L2 and L3
Next
Zenmuse L3 vs L2 vs P1: LiDAR or Photogrammetry for Canadian Surveying?