Booster K1 intergation

[Kaweees]

Problem

This merge request adds support for the Booster K1 robot, along with accompanying blueprints (booster-k1-basic, booster-k1, booster-k1-spatial, booster-k1-agentic).

Note

This relies on booster-rpc (GitHub source), a library I wrote that provides high-level control of the Booster K1 by interfacing with the same RPC and WebSocket protocols used by the Booster App. Through booster-rpc, Dimensional will be the first and only way to control the Booster wirelessly with no installation or SSH required. Additionally, the App and Dimensional can control the robot concurrently. In the future this will be generalized across all Booster robots

Closes DIM-583

Solution

Breaking Changes

None

How to Test

ROBOT_IP can be found on the Booster App

ROBOT_IP=10.0.0.15 uv run dimos --viewer rerun-web run booster-k1-agentic

Contributor License Agreement

• I have read and approved the CLA.

[greptile-apps]

Greptile Summary

This PR adds a full Booster K1 integration — connection module (K1Connection), four blueprints (booster-k1-basic, booster-k1, booster-k1-spatial, booster-k1-agentic), and the booster-rpc + websockets dependency declarations — enabling wireless control of the Booster K1 via its existing RPC/WebSocket protocols without any on-robot installation.

• The integration follows the established patterns from unitree_go2 / drone blueprints (viewer-backend branching at import time, @rpc/@skill annotations, cmd_vel subscription, ClockSyncConfigurator, mac transport workaround).
• All previous review issues have been resolved: duration is now honoured in move() with a timed hold and stop command; the KeyboardInterrupt flow-control hack is gone; logger f-string/positional-arg mismatch is fixed; @rpc uses the public _conn.call() API; stub output ports (pointcloud, odom, lidar) carry clear TODO comments; navigation modules are deferred until the hardware exposes the required streams.
• Two open items worth tracking: _camera_info_static() uses placeholder intrinsics (acknowledged by TODO) which will affect person_follow_skill geometric accuracy in the agentic blueprint; and booster_k1.py duplicates the .global_config(n_workers=4) already set by booster_k1_basic rather than bumping the count as the analogous unitree_go2.py does.

Confidence Score: 3/5

• Safe to merge for basic and agentic use, with the understanding that spatial/nav features are intentionally stubbed pending hardware support.
• All critical issues from prior review rounds have been addressed. The remaining open items are acknowledged TODOs (placeholder camera intrinsics, stub sensor ports) and a minor redundant global_config call — none of these block runtime correctness for the booster-k1-basic and booster-k1-agentic blueprints. The booster-k1-spatial blueprint includes spatial_memory which relies on camera data that is live, but any deeper nav functionality will silently no-op until odom/pointcloud streams are implemented. Score reflects the presence of multiple acknowledged stubs that could cause subtle silent failures in advanced blueprints.
• Pay close attention to dimos/robot/booster/k1/connection.py (stub output ports, cmd_vel RPC queuing) and dimos/robot/booster/k1/blueprints/smart/booster_k1.py (redundant global_config).

Important Files Changed

Filename	Overview
dimos/robot/booster/k1/connection.py	Core K1 integration module — previous review issues (duration handling, KeyboardInterrupt misuse, logger f-string args, private _call usage) are all addressed; stub output ports (pointcloud/odom/lidar) have TODO comments; cmd_vel subscription routes through @rpc which may queue commands under high-frequency nav streams.
dimos/robot/booster/k1/blueprints/basic/booster_k1_basic.py	Basic blueprint follows the same module-level viewer-backend branch pattern as unitree_go2_basic and drone_basic; mac transport workaround and rerun/foxglove split are consistent with the rest of the codebase.
dimos/robot/booster/k1/blueprints/smart/booster_k1.py	Navigation modules removed (with clear TODO comment) until K1 exposes odom/pointcloud streams; redundant .global_config() call sets the same n_workers=4 already set by booster_k1_basic rather than bumping the count for future nav components.
dimos/robot/booster/k1/blueprints/smart/booster_k1_spatial.py	Adds spatial_memory() and PerceiveLoopSkill on top of booster_k1; these components rely primarily on camera data which is live, so spatial perception should function; nav stack is deferred per TODO in parent blueprint.
dimos/robot/booster/k1/blueprints/agentic/booster_k1_agentic.py	Thin composition blueprint wiring booster_k1_spatial + agent + _common_agentic; straightforward and follows the established agentic blueprint pattern.
dimos/robot/booster/k1/blueprints/agentic/_common_agentic.py	Provides person_follow_skill seeded with placeholder camera intrinsics (TODO noted); incorrect intrinsics will degrade distance/angle accuracy in the follower but won't cause a crash.
dimos/robot/all_blueprints.py	Correctly registers the four new booster-k1 blueprints and the k1-connection module entry point; alphabetical ordering maintained.
pyproject.toml	Adds booster extra with booster-rpc>=0.0.8 and websockets>=13.0; python-socketio added to web extra to satisfy the existing websocket_vis_module.py dependency that was previously undeclared.

Sequence Diagram

sequenceDiagram
    participant Agent
    participant K1Connection
    participant BoosterRPC as BoosterConnection (RPC)
    participant VideoWS as Robot WebSocket (Video)
    participant Robot as Booster K1 Hardware

    Note over K1Connection: start() called
    K1Connection->>BoosterRPC: BoosterConnection(ip)
    K1Connection->>VideoWS: Thread: _run_video_stream()
    K1Connection->>K1Connection: Thread: _publish_camera_info()
    K1Connection->>K1Connection: cmd_vel.subscribe(self.move)

    loop Every 1s
        K1Connection-->>K1Connection: camera_info.publish(camera_info_static)
    end

    loop Video frames (WebSocket)
        VideoWS->>Robot: websockets.connect(ws://ip:port)
        Robot-->>VideoWS: JPEG bytes
        VideoWS->>K1Connection: _on_frame(jpeg_bytes)
        K1Connection-->>K1Connection: color_image.publish(image)
    end

    Agent->>K1Connection: walk(x, y, yaw, duration) [@skill]
    K1Connection->>K1Connection: move(twist, duration) [@rpc]
    K1Connection->>BoosterRPC: _conn.call(ROBOT_MOVE, req)
    BoosterRPC->>Robot: RPC → velocity command
    Note over K1Connection: time.sleep(duration)
    K1Connection->>BoosterRPC: _conn.call(ROBOT_MOVE, stop)
    BoosterRPC->>Robot: RPC → stop command

    Agent->>K1Connection: stand() [@skill]
    K1Connection->>K1Connection: standup() [@rpc]
    K1Connection->>BoosterRPC: call(GET_ROBOT_STATUS)
    Robot-->>BoosterRPC: status.mode
    K1Connection->>BoosterRPC: call(ROBOT_CHANGE_MODE, PREPARE)
    Note over K1Connection: time.sleep(3s)
    K1Connection->>BoosterRPC: call(ROBOT_CHANGE_MODE, WALKING)
    Note over K1Connection: time.sleep(3s)
    K1Connection->>BoosterRPC: call(GET_ROBOT_STATUS) [verify]

Loading

Comments Outside Diff (1)

1. dimos/robot/booster/k1/connection.py, line 129 (link)

   cmd_vel subscriber routes through RPC, can queue commands

   self.move is decorated with @rpc, so self.cmd_vel.subscribe(self.move) causes every incoming Twist to be dispatched as a separate RPC call. For continuous velocity streams (e.g., from a navigation planner or keyboard teleop), this means each message creates an independent RPC call that is queued and executed serially.

   When the navigation stack is eventually enabled (producing rapid cmd_vel updates), the queue could grow unbounded if the robot can't consume commands fast enough. The G1Connection uses the same pattern, so this may be intentional, but it's worth confirming that the @rpc dispatch queue has a bounded depth or that stale velocity commands are dropped rather than executed in sequence.

_{Last reviewed commit: 6886921}

[Kaweees]

@greptile

[Kaweees]

@greptile

[Kaweees]

@greptile

[Kaweees]

@greptile

[paul-nechifor]

I think K1Connection should not contain BoosterConnection directly.

For unitree, we put the connection inside UnitreeWebRTCConnection so that it can be easily swapped with MujocoConnection if the --simulation flag is passed.

I think you should add a class called BoosterHardwareConnection which contains BoosterConnection.

It would be nice in later PRs to add a simulation for it. I can't easily find one for K1, but mujoco_menagerie has mujoco files for T1 and there's a T1 policy here: https://github.com/google-deepmind/mujoco_playground/blob/main/mujoco_playground/experimental/sim2sim/onnx/t1_policy.onnx

[Kaweees]

I like the idea of a BoosterHardwareConnection, I'll add it.

As for the Mujoco side of Booster, I looked into it earlier and I was able to successfully train a policy for the Booster K1 in Mjlab (Mujoco with an Isaac Sim like API), I'll try deploying it tomorrow.

To go about integrating custom policies on the Booster, I think we should rename BoosterConnection to BoosterRPCConnection and BoosterSDKConnection for a low level adapter for the Booster Python SDK.

[paul-nechifor]

This try-except just hides errors. It's better to let them be visible.

[Kaweees]

As in change the logging type? If so, I changed it from logging.debug to logging.warning

[paul-nechifor]

Warning is better, but personally, I'd remove it entirely so the caller can receive the exception.

[paul-nechifor]

You have conflicts in this file. The best way to solve them is to delete everything in this dict and the one above and let the test regenerate the right values.