VisionProTeleop 架构全解析gRPC、WebRTC 与 RealityKit 如何协同工作【免费下载链接】VisionProTeleopVisionOS App Python Library to stream hand tracking data from Vision Pro, video/audio stream to Vision Pro.项目地址: https://gitcode.com/gh_mirrors/vi/VisionProTeleopVisionProTeleop 是一套用于机器人遥操作的开源架构它让 Apple Vision Pro 成为机器人的眼睛和手一端通过gRPC把手的骨骼追踪数据实时上行给 Python 客户端另一端通过WebRTC把机器人摄像头视频流下行回 Vision Pro再由RealityKit在空间里渲染仿真场景。本文将拆解这三大技术栈的分工与协作链路帮助你快速理解整套 VisionProTeleop 架构的核心设计。先看一张图VisionProTeleop 架构全景在深入代码之前先看项目自带的官方架构图它清晰地展示了数据如何在开发机、仿真器和 Vision Pro 三者之间流动从图中可以看到开发机上的物理仿真如 MuJoCo把模型和关节数据通过mujocoARViewer桥接层推送到 Vision ProVision Pro 侧的 RealityKit/ARKit 负责渲染与手势识别再把手腕、手指、头部的追踪结果回流给仿真形成闭环。项目的另一张高层示意图则展示了更完整的遥操作链路——头显采集人手动作指令流向机械臂、灵巧手和四足机器人等多种执行端VisionProTeleop 架构由哪三大组件构成VisionProTeleop 架构分为三个部分各司其职Tracking StreamerVisionOS 应用运行在 Vision Pro 上负责采集手/头追踪数据、接收视频/音频流、用 RealityKit 渲染仿真场景代码位于Tracking Streamer/目录avp_streamPython 库运行在你的电脑或机器人上负责接收追踪数据、把相机画面/仿真画面推回 Vision Pro核心实现在avp_stream/streamer.pyTracking ManageriOS 应用管理云端录像、摄像头标定与数据集分享Tracking Viewer/目录。三者通过两条数据高速公路通信gRPC 通道负责追踪数据上行与仿真控制WebRTC 通道负责视频/音频下行与跨网络直连。下面分别拆解。数据上行gRPC 如何传输手部追踪数据Vision Pro 采集到的手部骨骼数据走的是 gRPC 双向流。协议定义在avp_stream/grpc_msg/handtracking.proto中每个Hand消息包含手腕的 4x4 变换矩阵wristMatrix和一组关节矩阵skeleton每只手约 24~25 个关节HandUpdate再把左右手和头部数据打包成一次更新。Vision Pro 侧由Tracking Streamer/GRPCServer.swift启动 gRPC 服务器默认端口12345使用 grpc-swift 2 的HandTrackingServiceImpl实现StreamHandUpdates双向流接口。这里有个巧妙设计Python 客户端连上来后会先发一条特殊的发现消息把 IP 编码进矩阵字段Vision Pro 据此自动记住 Python 端的地址无需手动配置。Python 侧在avp_stream/streamer.py中通过VisionProStreamer连接这个服务把收到的骨骼矩阵换算成便于机器人使用的格式TrackingData并处理捏合距离、手腕旋转等特征相关工具函数见avp_stream/utils/grpc_utils.py。仿真控制MuJoCo AR 服务在 VisionProTeleop 架构中的作用如果你要遥操作的是仿真机器人VisionProTeleop 架构提供了第二组 gRPC 服务——MuJoCo AR。协议定义在avp_stream/mujoco_msg/mujoco_ar.proto服务端是Tracking Streamer/MuJoCo/MuJoCoGRPCServer.swift默认端口50051它实现了三类核心 RPC模型传输SendUsdzUrl/SendUsdzData/SendUsdzDataChunked把仿真场景的 USDZ 模型推送到 Vision Pro 空间里加载姿态流StreamPoses/UpdatePoses把仿真中每个刚体的位置、四元数姿态实时下发驱动 AR 场景里的模型运动手部追踪回流StreamHandTracking把 Vision Pro 的手部数据送回 Python用于闭环控制仿真机器人。Python 侧调用configure_mujoco()即可接入它会自动把 MuJoCo XML 转成 USDZ 发送到 Vision Pro再以 120Hz 的频率推送姿态更新实现仿真在 AR 中呈现的效果。数据下行WebRTC 如何把视频/音频送到 Vision Pro追踪数据是上行的而机器人相机画面是下行的——这趟旅程由WebRTC完成。Tracking Streamer/WebRTCClient.swift基于 LiveKitWebRTC 实现包含视频轨videoTrack、音频轨audioTrack以及若干DataChannel数据通道。avp_stream中的configure_video()把相机帧编码成 H.264 视频流通过 WebRTC 推送到 Vision Pro 显示configure_audio()类似地推送音频。相比把画面编码进 gRPCWebRTC 天生具备低延迟、抗抖动、自适应码率的优势非常适合实时遥操作场景。跨网络模式WebRTC DataChannel 与信令服务器同一 Wi-Fi 下两端直接用 IP 通信即可但机器人实验室往往在防火墙后面所以 VisionProTeleop 架构还提供了外部网络模式。流程是这样的Vision Pro 生成一个房间码并连接信令服务器infrastructure/signaling-server/基于 Cloudflare Worker 的 WebSocket 实现核心代码在src/index.tsPython 客户端用同一个房间码加入信令服务器完成 SDP 交换和 ICE 协商必要时借助 TURN 中继穿透 NAT连接建立后一切照旧。这套模式下USDZ 仿真模型也通过 WebRTC 的 DataChannel 分块传输WebRTCClient.swift中的UsdzTransferMetadata与分块重组逻辑Python 侧对应实现见avp_stream/streamer.py的_load_and_send_scene_webrtc()。项目还提供了avp_stream/bridge_avp.py帮助在两台主机之间搭建跨网络桥接。渲染层RealityKit 如何在空间里呈现仿真场景VisionProTeleop 架构的最后一公里是RealityKit渲染。Tracking Streamer/MuJoCo/MuJoCoStreamingView.swift使用 SwiftUI 的RealityView搭建 AR 场景收到 USDZ 后加载为ModelEntity并添加到场景收到姿态更新后按pythonToSwiftNameMap把 Python 端的关节名映射到 RealityKit 实体逐帧更新每个ModelEntity的Transform同时用 ARKit 的设备锚点把整个仿真场景放置在真实世界的桌面上实现空间对齐。这样你就能透过 Vision Pro 看到一只悬浮在桌面上的虚拟机械臂并用自己的手直接遥控它所有位姿都由 gRPC 通道实时驱动。其他组件如头部件、菜单面板Tracking Streamer/️Menu/等也都在这一渲染框架内协作。数据约定坐标系统与手部骨骼在架构中的意义多套系统协同坐标约定至关重要。VisionProTeleop 架构提供了两套标准来保证数据一致坐标系统上图区分 Z 轴向上ZUP仿真常用与 Y 轴向上YUP两种约定Python 侧se3_utils.py中的mat2posquat()、quaternion_to_matrix()等工具负责矩阵与四元数的换算手部骨骼约定下图定义了 27 个关节的编号与命名handWrist、各手指的 knuckle/tip 等保证从 ARKit 到手部数据的映射一致性能如何VisionProTeleop 架构的延迟表现遥操作对延迟极其敏感。项目内置了完整的延迟基准测试工具avp_stream/utils/latency_benchmark.py、avp_stream/latency_test.py可在视频帧中注入时间戳来测量端到端往返延迟。官方基准图展示了不同视频分辨率下的延迟表现实测数据也存放在benchmarks/目录有线/无线、单目/双目等组合项目用 WebRTC 时一般能达到较低延迟。值得一提的是verification_engine.py等模块还能在开发阶段验证追踪数据的正确性。总结三大技术栈如何拧成一股绳简单总结 VisionProTeleop 架构的分工gRPC负责控制面——手/头追踪数据上行端口 12345、仿真模型与姿态传输端口 50051特点是结构化、强类型、双向流WebRTC负责媒体面——视频/音频下行以及跨网络的 P2P 连接与 DataChannel 文件传输特点是低延迟、能穿透 NATRealityKit负责呈现面——在空间计算环境中加载 USDZ、渲染仿真、对齐真实世界坐标。三者各取所长、各司其职这正是 VisionProTeleop 架构的精妙之处gRPC 传指令WebRTC 传画面RealityKit 做舞台。无论你是想二次开发、接入新机器人还是研究空间遥操作方案沿着这三条主线去读源码VisionOS 端在Tracking Streamer/Python 端在avp_stream/都能很快上手。【免费下载链接】VisionProTeleopVisionOS App Python Library to stream hand tracking data from Vision Pro, video/audio stream to Vision Pro.项目地址: https://gitcode.com/gh_mirrors/vi/VisionProTeleop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 VisionProTeleop 架构全解析：gRPC、WebRTC 与 RealityKit 如何协同工作？
VisionProTeleop 架构全解析gRPC、WebRTC 与 RealityKit 如何协同工作【免费下载链接】VisionProTeleopVisionOS App Python Library to stream hand tracking data from Vision Pro, video/audio stream to Vision Pro.项目地址: https://gitcode.com/gh_mirrors/vi/VisionProTeleopVisionProTeleop 是一套用于机器人遥操作的开源架构它让 Apple Vision Pro 成为机器人的眼睛和手一端通过gRPC把手的骨骼追踪数据实时上行给 Python 客户端另一端通过WebRTC把机器人摄像头视频流下行回 Vision Pro再由RealityKit在空间里渲染仿真场景。本文将拆解这三大技术栈的分工与协作链路帮助你快速理解整套 VisionProTeleop 架构的核心设计。先看一张图VisionProTeleop 架构全景在深入代码之前先看项目自带的官方架构图它清晰地展示了数据如何在开发机、仿真器和 Vision Pro 三者之间流动从图中可以看到开发机上的物理仿真如 MuJoCo把模型和关节数据通过mujocoARViewer桥接层推送到 Vision ProVision Pro 侧的 RealityKit/ARKit 负责渲染与手势识别再把手腕、手指、头部的追踪结果回流给仿真形成闭环。项目的另一张高层示意图则展示了更完整的遥操作链路——头显采集人手动作指令流向机械臂、灵巧手和四足机器人等多种执行端VisionProTeleop 架构由哪三大组件构成VisionProTeleop 架构分为三个部分各司其职Tracking StreamerVisionOS 应用运行在 Vision Pro 上负责采集手/头追踪数据、接收视频/音频流、用 RealityKit 渲染仿真场景代码位于Tracking Streamer/目录avp_streamPython 库运行在你的电脑或机器人上负责接收追踪数据、把相机画面/仿真画面推回 Vision Pro核心实现在avp_stream/streamer.pyTracking ManageriOS 应用管理云端录像、摄像头标定与数据集分享Tracking Viewer/目录。三者通过两条数据高速公路通信gRPC 通道负责追踪数据上行与仿真控制WebRTC 通道负责视频/音频下行与跨网络直连。下面分别拆解。数据上行gRPC 如何传输手部追踪数据Vision Pro 采集到的手部骨骼数据走的是 gRPC 双向流。协议定义在avp_stream/grpc_msg/handtracking.proto中每个Hand消息包含手腕的 4x4 变换矩阵wristMatrix和一组关节矩阵skeleton每只手约 24~25 个关节HandUpdate再把左右手和头部数据打包成一次更新。Vision Pro 侧由Tracking Streamer/GRPCServer.swift启动 gRPC 服务器默认端口12345使用 grpc-swift 2 的HandTrackingServiceImpl实现StreamHandUpdates双向流接口。这里有个巧妙设计Python 客户端连上来后会先发一条特殊的发现消息把 IP 编码进矩阵字段Vision Pro 据此自动记住 Python 端的地址无需手动配置。Python 侧在avp_stream/streamer.py中通过VisionProStreamer连接这个服务把收到的骨骼矩阵换算成便于机器人使用的格式TrackingData并处理捏合距离、手腕旋转等特征相关工具函数见avp_stream/utils/grpc_utils.py。仿真控制MuJoCo AR 服务在 VisionProTeleop 架构中的作用如果你要遥操作的是仿真机器人VisionProTeleop 架构提供了第二组 gRPC 服务——MuJoCo AR。协议定义在avp_stream/mujoco_msg/mujoco_ar.proto服务端是Tracking Streamer/MuJoCo/MuJoCoGRPCServer.swift默认端口50051它实现了三类核心 RPC模型传输SendUsdzUrl/SendUsdzData/SendUsdzDataChunked把仿真场景的 USDZ 模型推送到 Vision Pro 空间里加载姿态流StreamPoses/UpdatePoses把仿真中每个刚体的位置、四元数姿态实时下发驱动 AR 场景里的模型运动手部追踪回流StreamHandTracking把 Vision Pro 的手部数据送回 Python用于闭环控制仿真机器人。Python 侧调用configure_mujoco()即可接入它会自动把 MuJoCo XML 转成 USDZ 发送到 Vision Pro再以 120Hz 的频率推送姿态更新实现仿真在 AR 中呈现的效果。数据下行WebRTC 如何把视频/音频送到 Vision Pro追踪数据是上行的而机器人相机画面是下行的——这趟旅程由WebRTC完成。Tracking Streamer/WebRTCClient.swift基于 LiveKitWebRTC 实现包含视频轨videoTrack、音频轨audioTrack以及若干DataChannel数据通道。avp_stream中的configure_video()把相机帧编码成 H.264 视频流通过 WebRTC 推送到 Vision Pro 显示configure_audio()类似地推送音频。相比把画面编码进 gRPCWebRTC 天生具备低延迟、抗抖动、自适应码率的优势非常适合实时遥操作场景。跨网络模式WebRTC DataChannel 与信令服务器同一 Wi-Fi 下两端直接用 IP 通信即可但机器人实验室往往在防火墙后面所以 VisionProTeleop 架构还提供了外部网络模式。流程是这样的Vision Pro 生成一个房间码并连接信令服务器infrastructure/signaling-server/基于 Cloudflare Worker 的 WebSocket 实现核心代码在src/index.tsPython 客户端用同一个房间码加入信令服务器完成 SDP 交换和 ICE 协商必要时借助 TURN 中继穿透 NAT连接建立后一切照旧。这套模式下USDZ 仿真模型也通过 WebRTC 的 DataChannel 分块传输WebRTCClient.swift中的UsdzTransferMetadata与分块重组逻辑Python 侧对应实现见avp_stream/streamer.py的_load_and_send_scene_webrtc()。项目还提供了avp_stream/bridge_avp.py帮助在两台主机之间搭建跨网络桥接。渲染层RealityKit 如何在空间里呈现仿真场景VisionProTeleop 架构的最后一公里是RealityKit渲染。Tracking Streamer/MuJoCo/MuJoCoStreamingView.swift使用 SwiftUI 的RealityView搭建 AR 场景收到 USDZ 后加载为ModelEntity并添加到场景收到姿态更新后按pythonToSwiftNameMap把 Python 端的关节名映射到 RealityKit 实体逐帧更新每个ModelEntity的Transform同时用 ARKit 的设备锚点把整个仿真场景放置在真实世界的桌面上实现空间对齐。这样你就能透过 Vision Pro 看到一只悬浮在桌面上的虚拟机械臂并用自己的手直接遥控它所有位姿都由 gRPC 通道实时驱动。其他组件如头部件、菜单面板Tracking Streamer/️Menu/等也都在这一渲染框架内协作。数据约定坐标系统与手部骨骼在架构中的意义多套系统协同坐标约定至关重要。VisionProTeleop 架构提供了两套标准来保证数据一致坐标系统上图区分 Z 轴向上ZUP仿真常用与 Y 轴向上YUP两种约定Python 侧se3_utils.py中的mat2posquat()、quaternion_to_matrix()等工具负责矩阵与四元数的换算手部骨骼约定下图定义了 27 个关节的编号与命名handWrist、各手指的 knuckle/tip 等保证从 ARKit 到手部数据的映射一致性能如何VisionProTeleop 架构的延迟表现遥操作对延迟极其敏感。项目内置了完整的延迟基准测试工具avp_stream/utils/latency_benchmark.py、avp_stream/latency_test.py可在视频帧中注入时间戳来测量端到端往返延迟。官方基准图展示了不同视频分辨率下的延迟表现实测数据也存放在benchmarks/目录有线/无线、单目/双目等组合项目用 WebRTC 时一般能达到较低延迟。值得一提的是verification_engine.py等模块还能在开发阶段验证追踪数据的正确性。总结三大技术栈如何拧成一股绳简单总结 VisionProTeleop 架构的分工gRPC负责控制面——手/头追踪数据上行端口 12345、仿真模型与姿态传输端口 50051特点是结构化、强类型、双向流WebRTC负责媒体面——视频/音频下行以及跨网络的 P2P 连接与 DataChannel 文件传输特点是低延迟、能穿透 NATRealityKit负责呈现面——在空间计算环境中加载 USDZ、渲染仿真、对齐真实世界坐标。三者各取所长、各司其职这正是 VisionProTeleop 架构的精妙之处gRPC 传指令WebRTC 传画面RealityKit 做舞台。无论你是想二次开发、接入新机器人还是研究空间遥操作方案沿着这三条主线去读源码VisionOS 端在Tracking Streamer/Python 端在avp_stream/都能很快上手。【免费下载链接】VisionProTeleopVisionOS App Python Library to stream hand tracking data from Vision Pro, video/audio stream to Vision Pro.项目地址: https://gitcode.com/gh_mirrors/vi/VisionProTeleop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考