feat(go2): rage mode via webrtc

[ruthwikdasyam]

Problem

No Rage Mode (~2.5 m/s forward velocity) on the Go2 via WebRTC

Solution

• Added enable_rage_mode() to WebRTC Connection using undocumented api_id 2059 (AI controller's FsmRageMode), with SwitchJoystick to route velocity commands through the existing WebRTC joystick channel
• Expose as rpc on GO2Connection so it can be called from any module/agent at runtime
• Added unitree-go2-webrtc-rage-keyboard-teleop blueprint with higher base speeds (1.25 m/s linear, 1.2 rad/s angular) tuned for rage's envelope

Breaking Changes

None

How to Test

dimos run unitree-go2-webrtc-rage-keyboard-teleop

Robot should stand up, enter Rage Mode (visible gait change), then accept keyboard velocity commands
WASD at base speed should move at ~1.25 m/s, Shift+W should hit ~2.5 m/s

Contributor License Agreement

• I have read and approved the CLA.

[greptile-apps]

Greptile Summary

This PR adds Rage Mode support for the Unitree Go2 via WebRTC, using undocumented api_id 2059 (FsmRageMode) followed by a SwitchJoystick command to route velocity through the existing joystick channel. It also refactors KeyboardTeleop to accept configurable speed parameters and introduces a new unitree-go2-webrtc-rage-keyboard-teleop blueprint tuned for the higher velocity envelope.

Confidence Score: 4/5

Safe to merge after addressing the unconditional True return in enable_rage_mode; the RPC state-guard concern is lower priority but worth noting.

Both findings are P2, but the unconditional True return is an inconsistency with every other command method's contract and could mask real failures silently — worth a fix before merging. The RPC guard concern is a documentation/safety hardening note. All other changes (KeyboardTeleop refactor, blueprint, stubs) are clean.

dimos/robot/unitree/connection.py — enable_rage_mode return value logic

Important Files Changed

Filename	Overview
dimos/robot/unitree/connection.py	Adds enable_rage_mode() using undocumented api_id 2059; method always returns True regardless of whether either publish_request call succeeds — inconsistent with every other command in the class.
dimos/robot/unitree/go2/connection.py	Adds Go2Mode enum, mode field to ConnectionConfig, triggers enable_rage_mode() after BalanceStand in start(); exposes enable_rage_mode as an @rpc without state precondition checks.
dimos/robot/unitree/go2/blueprints/basic/unitree_go2_webrtc_rage_keyboard_teleop.py	New blueprint composing existing keyboard-teleop with mode="rage" and higher speed limits (1.25 m/s linear, 1.2 rad/s angular); clean and straightforward.
dimos/robot/unitree/keyboard_teleop.py	Replaces hardcoded speed constants with constructor parameters (linear_speed, angular_speed, boost_multiplier, slow_multiplier); clean refactor with sensible defaults preserving existing behavior.
dimos/robot/unitree/mujoco_connection.py	Adds stub enable_rage_mode() returning True to satisfy the protocol; appropriate no-op for simulation.
dimos/robot/all_blueprints.py	Registers the new unitree-go2-webrtc-rage-keyboard-teleop blueprint entry; trivial and correct.

Sequence Diagram

sequenceDiagram
    participant B as Blueprint
    participant G as GO2Connection
    participant C as UnitreeWebRTCConnection
    participant R as Robot (WebRTC)

    B->>G: start() [mode=rage]
    G->>C: start()
    G->>C: standup()
    C->>R: SPORT_MOD {StandUp}
    Note over G: sleep(3s)
    G->>C: balance_stand()
    C->>R: SPORT_MOD {BalanceStand}
    Note over G: mode == RAGE
    G->>C: enable_rage_mode()
    C->>R: SPORT_MOD {api_id: 2059, data: true}
    Note over C: sleep(2s)
    C->>R: SPORT_MOD {SwitchJoystick, data: true}
    C-->>G: True (always)
    G->>C: set_obstacle_avoidance(true)
    C->>R: OBSTACLES_AVOID {enable: 1}
    Note over G: Robot ready — ~2.5 m/s envelope active

Loading

_{Reviews (1): Last reviewed commit: "feat: mode enum" | Re-trigger Greptile}

[leshy]

haha were you brave enough to test existing nav with rage mode on?

[ruthwikdasyam]

haha were you brave enough to test existing nav with rage mode on?

Nice idea, Notyet. will try increasing max velocity from 1m/s to max, step-by-step, and spectate behavior, untill out-of-control