Current State¶

Goal¶

Get the robot into an active state where it can be controlled via the Unitree SDK2 over wired Ethernet DDS.

Secondary goals: 1. Get the Unitree Explore app working reliably 2. Pair the remote controller 3. Update firmware via OTA 4. Deploy RL policies from the Kingston workstation

What Works¶

What Doesn't Work¶

1. DDS Data Flow (no samples published)¶

DDS infrastructure works perfectly, but zero data is published by any process on the locomotion board.

The g1_estimator_runner process registers rt/odommodestate (SportModeState_) as a publication, our reader matches with it, but the writer never publishes any samples. This is true for ALL 77 topics - none of them produce data.

Tested with: - SDK ChannelSubscriber on rt/odommodestate (correct topic name, not rt/sportmodestate) - SDK ChannelSubscriber on rt/lowstate, rt/wirelesscontroller - Raw CycloneDDS DataReader with BestEffort and Reliable QoS - Custom IDL String_ type on rt/selftest, rt/servicestate, rt/multiplestate - Listened for up to 25 seconds with no data

Root cause: The robot is likely in a boot standby state. Services start and register DDS topics, but the control loop does not begin until activated by the app or remote controller.

2. SDK RPC Calls (sport service)¶

LocoClient RPC calls fail with "send request error" (code 3102).

The SDK writes to rt/api/sport/request but publication_matched_count stays 0 - there is no subscriber for that topic on the locomotion board. The sport API server does not appear to be running or accepting external requests.

Note: Writing Request_ type objects causes segfaults on CycloneDDS 0.10.2 (ARM64). This affects direct DDS writes and the bashrunner service.

3. WiFi/STA Mode (locomotion board joining external WiFi)¶

Extensively tested - confirmed broken. The locomotion board accepts WiFi credentials via BLE but never actually connects to any WiFi network.

Tested with: - Unitree app on iPad (generic error: "check if WiFi password is correct...") - Phone hotspot (same failure) - Custom BLE script from Jetson via gatttool (all 6 BLE instructions ACK'd successfully, router logs show no connection attempt) - WG827 router WiFi "UnitreeRouter" / "Temp1234" (2.4GHz, WPA2, no special characters)

Router DHCP leases only ever show the iPad. The locomotion board never requests a DHCP lease. The WiFi chip on the locomotion board may be hardware-broken or firmware-disabled.

4. SSH Access to Locomotion Board¶

No SSH access available. Port 22 is closed on the locomotion board (192.168.123.161). No known method to enable it on firmware 1.4.5. See .private/g1-exploit-notes.md for details on attempts.

5. OTA Firmware Update¶

Cannot update firmware because: - WiFi mode does not work (locomotion board cannot reach Unitree servers via WiFi) - App in AP mode has no internet (192.168.12.x is isolated) - App connection is flaky (intermittent AP WiFi, WebRTC issues)

6. App Connectivity (intermittent)¶

The Unitree Explore app is extremely flaky: - AP WiFi ("UnitreeG1") sometimes does not broadcast at all - When it does broadcast, the app sometimes cannot connect to the robot - WebRTC services on the locomotion board may be abnormal - The app is hardcoded to look for the robot at 192.168.12.1 - App says "connected to access point" but then fails to connect to the robot itself - "Server inaccessible" errors frequent (catch-22: iPad on robot AP has no internet, but app needs cloud servers) - Successfully unbound the robot once (March 8), proving the app CAN talk to the robot briefly - Multiple retry sessions (March 8-9) with dozens of attempts, only sporadic brief connections - Tried connecting iPad via router WiFi (UnitreeRouter) for internet, then switching to G1 AP - did not help

7. Video feed (WebRTC)¶

All three app-side WebRTC services are abnormal on the locomotion computer, so Unitree Explore video streaming is broken.

Direct Jetson camera streaming works as a workaround. The Jetson runs Unitree's video_hub_pc4 service on /dev/video4, which publishes H.264/RTP multicast on 230.1.1.1:1720 from eth0. A short sample decoded successfully at 1280x720, and live playback works from the Mac over the wireless-only GL.iNet -> WG827 route by SSH-bridging that multicast stream.

DDS Topic Discovery (77 topics)¶

Discovered from Jetson via CycloneDDS builtin topic readers on eth0 (192.168.123.x wired network).

Robot State Topics¶

Sensor Topics¶

Hand/Dexterous Topics¶

SLAM/Navigation Topics¶

RPC Services (request/response)¶

Other Topics¶

DDS Processes on Locomotion Board¶

ROS2 Service Layer (via ros_bridge)¶

The ros_bridge process provides ROS2 service endpoints: - rq/locoRequest / rr/locoReply - rq/motion_switcherRequest / rr/motion_switcherReply - rq/robot_stateRequest / rr/robot_stateReply - rq/configRequest / rr/configReply - rq/voiceRequest / rr/voiceReply

Network Topology¶

Current TMU Operator Network¶

TMU Wi-Fi (WPA2-Enterprise)
  |
GL.iNet GL-MT3000 "eph107"
  |-- wwan: TMU DHCP, observed 10.16.144.207/20
  |-- 5 GHz radio: TMU station/uplink only; private 5 GHz AP disabled
  |-- 2.4 GHz AP: GL-MT3000-8b4 local downlink
  |-- LAN: 192.168.8.1/24
  |-- Tailscale: 100.84.198.19
  |
  +-- Mac Wi-Fi (en0) 192.168.8.109
  +-- Jeff Xi Ubuntu host
  |     |-- Ethernet 192.168.8.241, primary
  |     |-- Wi-Fi 192.168.8.242, backup
  |     |-- Home Assistant http://192.168.8.241:8123/
  |     +-- Tailscale 100.108.86.74
  +-- iDevices Switch 00101614 192.168.8.115
  |     +-- Home Assistant entity switch.switch_00101614 (main robot power)
  +-- operator devices / tablets / robot tools 192.168.8.x

The GL.iNet gives operator machines stable internet and tailnet access. The Mac still uses a separate USB Ethernet adapter to the G1 neck port for direct SDK/DDS work when low-jitter local DDS is needed. jeffxi-ubuntu is an Ubuntu 22.04.5 desktop on the GL.iNet LAN; its eno1 Ethernet has a DHCP reservation at 192.168.8.241, and Wi-Fi is enabled as a lower-priority backup at 192.168.8.242.

Legacy G1 Wired Network¶

Internet
  |
Mac (en0) -- NAT via pfctl (now usually through GL.iNet Wi-Fi)
  |
Mac (en13) 192.168.123.100 -- USB ethernet to robot
  |
  +-- Router (br-lan) 192.168.123.1 -- WG827 OpenWrt, WiFi "UnitreeRouter"
  |     |
  |     +-- iPad 192.168.123.214 (via router WiFi)
  |
  +-- Jetson (eth0) 192.168.123.164
  |     |
  |     +-- Jetson (wlan0) 192.168.12.127 (connected to robot AP WiFi, when available)
  |
  +-- Locomotion board (wired) 192.168.123.161, port 8081 (aiohttp, 404 for all paths)
        |
        +-- Locomotion board (wlan1 AP) 192.168.12.1, "UnitreeG1" (intermittent)
              |
              +-- iPad 192.168.12.x (when on robot AP)
              +-- Jetson 192.168.12.127 (via wlan0)

Current WG827 GL.iNet Uplink Mode¶

The WG827 is not internal G1 infrastructure; it is an external/add-on router velcroed to the robot and plugged into the robot's 192.168.123.0/24 Ethernet network.

TMU Wi-Fi (WPA2-Enterprise)
  |
GL.iNet GL-MT3000 "eph107" 192.168.8.1
  |-- DHCP reservation: WG827 f8:5e:3c:ee:42:5e -> 192.168.8.190
  |-- static route: 192.168.123.0/24 via 192.168.8.190
  |
WG827 wlan0 192.168.8.190/24
WG827 br-lan 192.168.123.1/24
  |
G1 wired 192.168.123.0/24
  +-- Jetson eth0 192.168.123.164, default via 192.168.123.1
  +-- Locomotion board 192.168.123.161
  +-- Livox 192.168.123.20

Verified:

• WG827 uses GL-MT3000-8b4 as its upstream.
• GL.iNet has a persistent DHCP reservation for WG827 MAC f8:5e:3c:ee:42:5e at 192.168.8.190.
• GL.iNet has a persistent static route for 192.168.123.0/24 via 192.168.8.190.
• GL.iNet 2.4 GHz backhaul is pinned to channel 11, HE20, with legacy rates disabled.
• WG827 firewall allows GL LAN clients (192.168.8.0/24) to reach the robot LAN and WG827 SSH/web/ping.
• DHCP is split: GL.iNet serves 192.168.8.0/24; WG827 serves only 192.168.123.0/24 and ignores DHCP on wwan2.
• Mac Wi-Fi no longer has the old 192.168.123.100 alias; routed access goes through GL.
• Jetson can ping 1.1.1.1 and resolve DNS through the WG827.
• Mac can SSH to the WG827 and Jetson with the GL-to-WG827 Ethernet cable unplugged.
• UnitreeRouter AP is disabled in this mode. AP+STA on the same MT7603E radio failed on GoldenOrb; use the GL.iNet AP for operator devices instead.
• Direct TMU from the WG827 was tested and works as a fallback after fixing the router clock, but it is not the preferred mode.

Locomotion Board Port Scan¶

Scanned from both 192.168.123.x and 192.168.12.x interfaces:

SDK Details¶

Installed on Jetson: - unitree_sdk2_python v1.0.1 (latest git master from GitHub) - CycloneDDS 0.10.2 (required version, pinned in setup.py) - Python 3.8

Key SDK files: - ~/unitree_sdk2_python/example/g1/high_level/g1_loco_client_example.py - interactive locomotion control - ~/unitree_sdk2_python/example/g1/low_level/g1_low_level_example.py - direct motor control - ~/unitree_sdk2_python/unitree_sdk2py/g1/loco/g1_loco_client.py - LocoClient class - ~/unitree_sdk2_python/unitree_sdk2py/g1/loco/g1_loco_api.py - LOCO_SERVICE_NAME = "sport"

SDK channel naming: - Client request: rt/api/{service}/request - Client response: rt/api/{service}/response

Known SDK bug: Writing Request_ type objects with CycloneDDS 0.10.2 on ARM64 (Jetson) causes segfaults. The binary field (sequence[uint8]) serialization appears broken.

Legacy Mac-NAT Router Config¶

This section is for the robot-mounted WG827 on the G1 wired network, not the GL.iNet field router.

Use this only when the WG827 is not joined to the GL.iNet or TMU. In the current GL.iNet-uplink mode, the WG827 itself is the robot internet gateway and these Mac NAT commands are not needed.

# SSH into router
sshpass -p 'indr0.com' ssh -o StrictHostKeyChecking=no root@192.168.123.1

# Add default route through Mac
ip route add default via 192.168.123.100 dev br-lan

# Open firewall for forwarding
iptables -P FORWARD ACCEPT
iptables -F FORWARD

# Disable ICMP redirects (prevents hairpin routing issues)
echo 0 > /proc/sys/net/ipv4/conf/br-lan/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

# Fix DNS
echo "nameserver 8.8.8.8" > /etc/resolv.conf

Why this is needed: The locomotion board uses 192.168.123.1 (router) as its default gateway. Traffic from .161 goes to the router, which forwards to the Mac (.100), which does pfctl NAT to the internet. Without the firewall fix, the router FORWARD chain has policy DROP and blocks all forwarded traffic.

Verification: Check sudo pfctl -s state | grep 192.168.123.161 on the Mac - you should see ZeroTier and DNS connections from the locomotion board.

Jetson DNS Fix (must re-apply after each robot reboot)¶

The Jetson loses DNS and default route after reboot:

sshpass -p '123' ssh -o StrictHostKeyChecking=no unitree@192.168.123.164
echo "123" | sudo -S bash -c "echo nameserver 8.8.8.8 > /etc/resolv.conf"
echo "123" | sudo -S ip route replace default via 192.168.123.100 dev eth0

ZeroTier VPN (Unitree backdoor)¶

The locomotion board runs ZeroTier and connects to Unitree root servers when it has internet: - root-sgp-01.zerotier.com (Singapore) - root-zrh-01.zerotier.com (Zurich) - root-mia-01.zerotier.com (Miami)

This is a VPN overlay that gives Unitree remote access to the robot. Confirmed by ARP table entries on the router and pfctl state table on the Mac.

MITM AP Approach (March 9, tested)¶

Attempted to create a fake "UnitreeG1_W" WiFi AP on the Jetson to proxy app traffic to the real robot over wired ethernet:

1. Set up hostapd on Jetson wlan0 (2.4GHz, channel 6, WPA2, password "Temp1234")
2. Configured Jetson as 192.168.12.1/24 (same as real robot AP IP)
3. Set up iptables DNAT: all traffic to 192.168.12.1 on wlan0 -> 192.168.123.161 (real robot over wire)
4. MASQUERADE on eth0 for return traffic, FORWARD rules both directions
5. dnsmasq for DHCP on wlan0

Result: iPad connected to the fake AP and got internet through the Jetson -> Mac NAT chain. But the Unitree app never sent any traffic to 192.168.12.1. The app only contacted external servers (Unitree cloud, Apple, DNS). The DNAT rule had zero packet matches.

Conclusion: The app does not blindly connect to 192.168.12.1. It either uses mDNS/Bonjour discovery or requires cloud server authentication before connecting to the robot locally. The MITM approach needs an mDNS responder or deeper understanding of the app protocol.

Recommended Next Steps¶

1. Contact Unitree support (highest priority) - provide serial E21D6000P9GCAE, describe: WiFi STA broken, app connectivity flaky, DDS services running but not publishing data. Ask if they can push firmware update or factory reset via ZeroTier while robot has internet through wired NAT setup. Draft Discord message prepared (see below).
2. Motherboard replacement - TMU was already considering this. May be the fastest path to a working robot.
3. Get the app working - the app is flaky but sometimes connects. If it connects reliably, try pairing the remote controller and activating the robot. Once active, DDS data should flow.
4. Try the Jetson upgrade web UI - http://192.168.123.164/#/ has a "Recover Last Version" button that runs backup.zip (231 MB). This only affects the Jetson, not the locomotion board.
5. Rockchip USB boot mode (last resort, voids warranty) - open chassis, find RK3588 recovery button, flash firmware via rkdeveloptool. Requires firmware image from Unitree or TheRoboVerse community. No factory reset button exists on the G1.