企业官网建设流程全解析

DimOS DimTELE如何工作：WebRTC托管式遥操作架构深度解析

【免费下载链接】dimosDimensional is the agentic operating system for physical space. Command humanoids, quadrupeds, drones, and other hardware platforms in natural language and build multi-agent systems that work seamlessly with physical input (cameras, lidar, actuators).项目地址: https://gitcode.com/GitHub_Trending/dimo/dimos

dimTELE 是 dimOS（Dimensional 机器人操作系统）内置的托管式遥操作（hosted teleoperation）组件：你可以在任何浏览器或 Quest 头显里，通过 WebRTC 远程驾驶 Go2 四足机器人等硬件平台。它最大的特点是机器人主动向外拨号（dial-out）连接云端 broker，因此无需在机器人网络上开放任何入站端口——家庭路由器、Wi-Fi、有线局域网甚至蜂窝网络后面都能直接工作。本文带你深入拆解它的三方架构、会话建立流程与数据通道设计。

核心关键词速览

• dimTELE / 托管式遥操作：官方文档中 dimTELE 即 "hosted teleoperation"，操作者通过 WebRTC 连接机器人
• Broker（中继代理）：位于机器人与操作者之间，负责视频、小地图、遥测与控制指令的中继，并处理登录与权限
• WebRTC DataChannel + 视频轨道：一个RTCPeerConnection同时承载视频流与 4 条数据通道

三方架构：机器人、Broker、操作者浏览器

dimTELE 的连接模型非常清晰：你从不直接连接机器人。

robot broker (Cloudflare) operator browser/Quest ───── ─────────────────── ────────────────────── POST /api/v1/sessions ───► session + datachannels ◄─── operator joins cmd_unreliable ◄──── (operator → robot, lossy) ◄──── WASD / Joy state_reliable ◄──── (operator → robot, json) ◄──── ping, video_stats, estop state_reliable_back ────► (robot → operator, json) ────► pong, robot_telemetry, cmd_ack map_unreliable ────► (robot → operator, lossy) ────► minimap grid + odom video track ────► broker publishes + pulls ────► <video> sink

1. 机器人拨出（The robot dials out）：运行teleop-hosted-go2-*蓝图后，机器人向 broker 发起出站 WebRTC 会话并注册自己。因为连接由机器人主动发起，不需要端口转发，可穿透任意 NAT。
2. Broker 桥接（The broker bridges）：broker 居中转发视频、小地图、遥测和指令，同时负责登录与"哪个操作者能连哪台机器人"的权限决策。
3. 浏览器接入（You connect from the browser）：在控制台选择机器人、点击Connect，浏览器拉取视频轨道并打开指令/遥测数据通道。

连接成功后，四条流持续流动：

所有面向 broker 的模块共享同一个会话——每台机器人只有一路视频轨道和一个控制平面。

会话如何建立：6 步拨号流程

整个会话（拨号、DataChannel 生命周期、视频轨道）由进程级的BrokerProvider（位于dimos/protocol/pubsub/impl/webrtc/providers/）统一管理。完整流程：

1. 机器人创建RTCPeerConnection（必须使用 MAX_BUNDLE），添加视频轨道与只收音频 transceiver，并打开一个预留的 SCTP id 0 一次性 DataChannel，随后创建 offer、收集 ICE（non-trickle）；
2. 机器人POST /api/v1/sessions把 offer 发给 broker，broker 创建会话并返回 answer 与以机器人为键的session_id；
3. 在setRemoteDescription前，把 SDP answer 中的 candidates 跨捆绑 m-section 传播（aiortc 兼容处理）；
4. 心跳任务轮询/sessions/{id}/heartbeat，每次 ack 携带 broker 分配的cmd_unreliable、state_reliable、state_reliable_back、map_unreliable四个通道的 SCTP id。机器人据此打开/重开/关闭协商通道；当state_reliable的 id 消失时，说明操作者已离开——机器人随即停止运动；
5. pc.connectionState == "connected"后，CameraVideoTrack.arm()才开始下发帧（丢弃操作者尚未真正能接收之前的所有帧）；
6. 遥测线程以telemetry_hz频率把指令面统计（入站 twist 流的延迟/抖动/速率）推回state_reliable_back，让操作者 HUD 显示的是实际到达的指标，而不是"发了多少"。

一个精妙的细节：普通createDataChannel会自动抢占 SCTP id 1，而 broker 恰好常把cmd_unreliable分配到 id 1，冲突会直接抛错。因此机器人在 offer 阶段就钉死一个一次性通道到 id 0（id 0 是保留值，broker 永远不会分配），它同时强制 offer 中生成 SCTP m-line，为真实通道提供绑定载体——而且这个通道必须保持打开，否则在 MAX_BUNDLE 下可能连带视频传输一起断掉。

四条数据通道：可靠性按需分配

由于 Cloudflare Realtime 桥接数据通道是单方向的（发布者→订阅者），每个方向都需要一条独立通道：

设计哲学一目了然：驾驶指令走"丢帧可接受"的无重传通道保证低延迟（松键即停，丢包绝不 coasting），而 E-STOP、导航目标等必须送达的控制走可靠通道，遥测与心跳也在可靠通道上闭环。

低延迟实测：四洲互踢足球有多快？

官方在世界杯期间做过一次极端压测：旧金山、班加罗尔、布宜诺斯艾利斯、上海的四位团队成员，隔着公网与托管在旧金山的 Go2 机器人实时踢球。记录到的往返指令延迟：

• 旧金山 →约 15 ms
• 班加罗尔 →约 114 ms
• 布宜诺斯艾利斯 →约 134 ms
• 上海 →约 160 ms

所有路线都低于典型视频通话约 200 ms 的延迟。该图的原始数据见 latency_four_continents.png（仓库中图片为 LFS 管理文件，在支持 LFS 的客户端 checkout 后可见）。

操作体验：WASD 驾驶、点击导航与 E-STOP

浏览器端是模态无关的——它只把设备输入流出去，由机器人蓝图决定如何处理：

按住Shift2 倍速、Ctrl半速；松开按键的瞬间机器人即停。此外你还可以：

• 🗺️小地图点击导航：点任意位置发送导航目标，机器人自主规划并避障到达；手动驾驶随时接管并取消规划；
• 🤖姿态与特技指令：Stand / Sit / Recovery / Damp、Hello、Stretch；开启--allow-acrobatics=true后可解锁 FrontJump 与 FrontPounce。每条指令都有确认回执，UI 显示的是机器人实际执行的动作；
• 🛑E-STOP：永远可用，立即停止所有运动、取消导航并阻尼，优先级高于一切在途指令，清除前机器人不会再次移动。

🎧 在 Go2 上还有一个亮点：操作者的麦克风 PCM 经go2_audio_bridge.py转发到 Go2 Pro 的扬声器（通过 Unitree 官方 WebRTC 音频枢纽 API），实现远程"喊话"。扬声器路由可通过go2audiobridgemodule.speaker=auto/enabled/disabled配置。

快速上手：两行命令连上你的机器人

1. 在 Dimensional 控制台创建 API key（一个 key 通吃 CLI、上传与遥操作）；
2. 在机器人侧启动托管蓝图：

TRANSPORTS__BROKER__API_KEY=dimos_sk_... \ dimos run teleop-hosted-go2-transport

打开控制台 Teleop 页面，你的机器人会出现在Available Robots下，点击Connect即可驾驶。可用蓝图：

启用--latency-stamp=true可叠加玻璃对玻璃（glass-to-glass）延迟基准条；搭配 recorder 还可录制会话并在断开时生成统计报告。

架构背后的模块设计

dimTELE 的一个关键工程取舍：每个关注点都是独立小模块，但它们都跑在同一个 worker 里共享唯一的 broker 会话（GO2Connection驱动跑在第二个 worker，n_workers=2）。各模块职责：

• go2_command.py —Go2CommandModule：操作指令与 E-STOP 分发、手动驾驶守卫，通过@rpc触达驱动；
• camera_mux.py —CameraMuxModule：N 路相机 → 一路合成、限帧的视频轨道；
• map_compress.py —MapCompressModule：costmap + 里程计 → 小地图通道（粗化 + PNG 编码，压在 32 KB 预算内——Cloudflare 会丢弃超过约 64 KB 的消息）；
• go2_audio_bridge.py —Go2AudioBridgeModule：操作者麦克风 PCM → Go2 扬声器；
• HostedStatsModule— 遥测帧、指令确认与链路延迟/速率统计。

安全边界同样由机器人侧兜底：指令超过cmd_stale_after_sec（默认 0.5s）即丢弃、线速度/角速度被max_linear_mps（1.5）/max_angular_rps（2.0）钳制、超过max_nav_goal_m（100m）的点击导航目标直接拒绝。damp_on_operator_lost=true时，操作者链路断开会自动让机器人进入阻尼状态。

断线重连方面，操作者侧重连由 broker 处理：broker 先关闭过期的state_reliable_back推送再重新推送（Cloudflare 不会自动回收 datachannel 推送，否则会累积"半死"推送导致 502）。机器人侧自动重拨仍是待办事项，但 TURN 已落地（broker 签发凭证 + STUN 回退），网络穿透已不再是阻塞点。

延伸阅读与源码导航

一句话总结：dimTELE 用"机器人主动拨出 + broker 桥接 + 单会话多模块"的架构，把 WebRTC 的音视频能力与机器人控制平面缝合在一起——零端口、穿任意 NAT、四洲延迟可控，让"在浏览器里开机器人"真正可用。

【免费下载链接】dimosDimensional is the agentic operating system for physical space. Command humanoids, quadrupeds, drones, and other hardware platforms in natural language and build multi-agent systems that work seamlessly with physical input (cameras, lidar, actuators).项目地址: https://gitcode.com/GitHub_Trending/dimo/dimos