7.2 KiB

Raw Blame History

id	title	status	source_sections	related_topics	key_equations	key_terms	images	examples	open_questions
networking-comms	Networking & Communications	established	reference/sources/official-quick-start.md, reference/sources/official-developer-guide.md	[sdk-programming ros2-integration deployment-operations]	[]	[dds cyclone_dds domain_id dual_computer_architecture locomotion_computer development_computer]	[]	[]	[WiFi 6 range and reliability in field conditions DDS QoS profile details and tuning WiFi AP exact SSID format and default password USB port availability and specs]

Networking & Communications

Network architecture, connectivity, remote access, and communication protocols.

1. Network Architecture

The G1 uses a fixed internal subnet with pre-assigned IP addresses: [T0 — Developer Guide]

                    192.168.123.0/24
                          │
    ┌─────────────────────┼──────────────────────┐
    │                     │                      │
Locomotion          Development              LiDAR
Computer            Computer              (Livox MID360)
192.168.123.161    192.168.123.164        192.168.123.20
(Proprietary)      (Jetson Orin NX)       (Ethernet)
    │                     │
    └──── CycloneDDS ─────┘
          (internal)

IP Address Map

Device	IP Address	Access Level
Locomotion Computer	192.168.123.161	Not user-accessible
Development Computer	192.168.123.164	User-accessible (SSH)
Livox MID360 LiDAR	192.168.123.20	Ethernet, driver required
External dev machine	192.168.123.x	Via WiFi or Ethernet

2. Connectivity Options

Interface	Specification	Purpose	Tier
WiFi	WiFi 6 (802.11ax)	Wireless development, remote control	T0
Bluetooth	Bluetooth 5.2	Peripheral connectivity	T0
Ethernet	Wired connection	LiDAR, high-bandwidth data	T0
USB	Available on dev computer	Camera (D435i), peripherals	T1

3. DDS Configuration

The entire communication stack is built on DDS (Data Distribution Service): [T0]

Property	Value
Implementation	CycloneDDS
Version	0.10.2 (exact match required)
Protocol	RTPS (Real-Time Publish-Subscribe)
Communication latency	2 ms
Control loop rate	500 Hz

Domain ID

The DDS domain ID controls which "network" of DDS participants can communicate:

Real robot: Use the robot's network interface (e.g., enp2s0, wlan0)
Simulation: Use domain ID to separate simulated robot traffic from real
Switch: Changing from sim to real only requires switching the network config (domain ID + interface)

Topic Architecture

All robot communication uses DDS topics (see sdk-programming for full topic list):

Publishers (user) ──→ rt/lowcmd    ──→ Locomotion Computer (motor commands)
Subscribers (user) ←── rt/lowstate ←── Locomotion Computer (robot state)
Publishers (user) ──→ rt/dex3/*/cmd ──→ Hand Controller (hand commands)
Subscribers (user) ←── rt/dex3/*/state ←── Hand Controller (hand state)

4. Remote Access

SSH: Connect to development computer: ssh unitree@192.168.123.164 (password: 123) [T1 — Weston Robot guide]
Data streaming: DDS topics accessible from any machine on the 192.168.123.0/24 subnet [T0]
Camera streaming: D435i frames accessible via RealSense SDK on dev computer [T1]
LiDAR data: Point cloud data from Livox MID360 at 192.168.123.20 [T0]

Connecting an External Development Machine

Connect to robot's WiFi network or plug into Ethernet
Configure machine's IP to 192.168.123.x (avoid .161, .164, .20)
Install CycloneDDS 0.10.2 and unitree_sdk2
Subscribe to rt/lowstate to verify connectivity

5. Latency Considerations

Path	Latency	Notes
DDS internal (dev ↔ locomotion)	~2 ms	CycloneDDS over internal net
WiFi (external ↔ dev computer)	Variable	Depends on WiFi conditions
Control loop	2 ms (500 Hz)	Locomotion computer rate
LiDAR point cloud	—	Depends on scan rate

Critical: For real-time control, use wired Ethernet or develop directly on the Jetson to minimize latency. WiFi adds variable latency that can affect control stability. [T2]

6. Offboard Compute — GB10 to G1 DDS Bridge (Verified 2026-02-15) [T1]

Connecting the Dell Pro Max GB10 to the G1's internal DDS network via Ethernet switch.

Network Topology (Verified)

[G1 Robot Internal Switch]
  ├── Locomotion Computer: 192.168.123.161 (eth0)
  ├── Jetson Orin NX: 192.168.123.164 (eth0) + 10.0.0.64 (wlan0)
  └── External Ethernet port ──► User's network switch
                                      │
                                  GB10: 10.0.0.68 (primary, DHCP)
                                      + 192.168.123.100/24 (secondary, manual)
                                  Interface: enP7s7

Setup Steps

Add secondary IP: sudo ip addr add 192.168.123.100/24 dev enP7s7
Verify ping: ping 192.168.123.161 (should be <1ms)
Critical: Disable or allow DDS through firewall: sudo ufw allow from 192.168.123.0/24

DDS Debugging Findings

DDS multicast (239.255.0.1:7400) IS active on the robot's internal network — 342 packets/4s confirmed from Jetson
Locomotion computer (192.168.123.161) publishes discovery continuously
UFW firewall was the root cause of DDS failure — it blocks incoming UDP multicast by default
Once firewall allows 192.168.123.0/24 traffic, DDS discovery and rt/lowstate subscription should work
Use ChannelFactoryInitialize(0, "enP7s7") or --interface real (auto-detects 192.168.123.x interface)

SSH Credentials (Verified)

Jetson: ssh unitree@192.168.123.164 — password: 123 (NOT "unitree") [T1]
Locomotion computer (192.168.123.161): Not user-accessible via SSH

Tools on GB10

/tmp/dds_test.py — Quick DDS connectivity test (ping → multicast → SDK rt/lowstate)
~/GR00T-WholeBodyControl/launch_real.sh — Launches GR00T-WBC with --interface real

Key Relationships

Transports: sdk-programming (SDK commands and data via DDS)
Transports: ros2-integration (ROS2 topics via same DDS layer)
Affects: deployment-operations (remote operation reliability)
Connected to: sensors-perception (LiDAR network address)
Connected to: gb10-offboard-compute (offboard AI compute via DDS bridge)

7.2 KiB Raw Blame History