XR笔记-Extended Reality核心概念总结

Extended Reality

1. Physical World 人、实验台、机器人、仪器、房间 ↓ sensors 2. Tracking / Spatial World Head pose、hand pose、地图、平面、anchor、reference spaces ↓ coordinate transforms 3. Application / Digital World Unity Scene、虚拟物体、UI、robot digital twin、interaction logic ↓ stereo rendering 4. Perceptual World 左眼图像、右眼图像、passthrough、声音、触觉 ↓ human action 回到 Physical World，形成闭环

1. 基本概念

• XR：扩展现实（Extended Reality, XR）是一个总称，包含虚拟现实（VR）、增强现实（AR）和混合现实（MR）等技术。

  • VR：

    • 用户看不到或基本看不到真实环境；
    • 视觉主要由计算机生成；
    • 用户的头和手被追踪；
    • 虚拟摄像机随用户运动；
    • 用户感到自己“处于”虚拟空间中。

    例如纯虚拟的 MuJoCo 机器人实验室，就是 VR 场景。

  • AR：

    • 增强现实（Augmented Reality, AR）强调：

      • 用户仍然看见现实世界；
      • 虚拟信息叠加在现实之上；
      • 叠加内容可以是文字、箭头、图标或 3D 物体。

      手机摄像头画面上叠加导航箭头是典型 AR。

  • MR

    • 混合现实（Mixed Reality, MR）通常比 AR 多强调一层：

      虚拟内容不仅显示在现实之上，还理解并参与现实空间。
      例如：

      • 虚拟试管放在真实桌面上；
      • 虚拟机器人被真实桌子遮挡；
      • 用户可以把虚拟面板固定在实验设备旁；
      • 虚拟球可以碰撞真实墙面的空间模型。

• Spatial Computing：持续计算“设备在哪、房间长啥样、每个真实/虚拟物体在三維空间里的位姿（位置+朝向）、它们互相怎么挡、怎么碰”的一整套过程。

2. XR 流程

• MR——真实世界
  • 人做抓取手势，Quest hand tracking 提供 hand joint pose 和 pinch state，Unity 据此更新 Hand GameObject。
  • 真实培养皿通过 Passthrough 直接可见，因此 Unity 不需要渲染其 Mesh；但 Unity 需要维护一个带 Collider 的 invisible proxy。
  • 培养皿的 pose 不能简单认为由 SLAM/Scene API 自动提供，而需要 object tracking、marker、robot vision 或预先 registration 等方式获得，并转换到 Unity/XR 坐标系。
  • 当手与 proxy 重叠并检测到 pinch 时，Unity 将其解释为Pick(target)高层交互事件，经 ROS 发送给机器人控制侧；机器人端经过坐标变换、grasp planning、IK 和控制执行真实抓取。
  • 真实机器人和培养皿直接通过 Passthrough 被用户看到，机器人/物体状态则可以继续回传 Unity 用于 digital twin、overlay 和状态同步。
• VR——虚拟世界
  • 人做抓取手势，Quest hand tracking 更新 Unity 中的 Hand GameObject；手与虚拟培养皿 GameObject 的 Collider 重叠并 pinch 后，Unity 产生Pick(target)事件，通过 WebSocket 发送给 Python 控制侧。
  • Python 中的 grasp planner / IK / controller 计算机器人控制量，MuJoCo 负责具体虚拟世界物理状态的模拟。
  • MuJoCo 是 simulation physics 的 ground truth。其机器人和培养皿状态持续回传 Unity，经过MuJoCo → Unity 坐标系转换后更新对应 GameObject 的 Transform，最终由 Unity/Quest 渲染，因此用户看到虚拟机器人抓取虚拟培养皿。

3. 设备与Tracking

3.1 HMD

• 头戴式显示设备（Head-Mounted Display, HMD）是戴在头上的显示和传感设备。Meta Quest（一个铲平）就是 HMD。

  • 独立式头显（standaloneheadset）意味着：

    • 计算处理器在头显中；

    • Unity 应用直接运行在头显；

    • 不需要 PC 持续参与；

    • Quest 的操作系统、追踪、应用和渲染都在设备端运行。

  • PC 驱动的虚拟现实（PC Virtual Reality,PCVR）意味着：

    • 应用和主要渲染运行在 PC；

    • 头显主要提供 tracking、显示和输入；（tracking就是获取当前位置和朝向）

    • 图像从 PC 传输到头显。

• Quest 可以同时扮演两种角色：

  • standalone：Android 应用直接运行在 Quest；

  • Link 类模式：作为连接 PC 的 PCVR 头显。

  • 这两种模式的运行位置和可用功能并不完全相同。

3.2 See-Through

3.2.1 OST: Optical See-Through

• 光学透视（Optical See-Through）是指真实光线直接穿过透明光学组件进入眼睛，虚拟图像叠加其上。

3.2.2 VST: Video See-Through

• 视频透视（Video See-Through）是指：

  现实世界 ↓ physical cameras camera images ↓ digital composition 虚拟内容 + camera images ↓ opaque displays 用户眼睛

  • Quest 的 passthrough 属于视频透视。Passthrough 可以理解为“由系统提供的现实世界视频背景”。

    • 视频透视更容易实现：

      • 虚实合成；颜色处理；虚实遮挡；

      • 完全 VR 与 MR 间切换。

    • 代价是：

      • 摄像头和显示链路引入延迟；视觉质量受摄像头影响；

      • 应用访问摄像头涉及隐私和权限。

  • Quest具体操作思路：

    Quest Camera ↓ Passthrough Layer ├─────────────┐ │ │ ▼ ▼ Real-world video Unity virtual objects └──────┬──────┘ ↓ XR Compositor ↓ Final Display

    • Unity 主要负责告诉系统：

      “我这里要画一个虚拟箭头 / UI / robot / hologram。”

      而 Quest Runtime / compositor 负责最终显示合成。

3.3 Pose

3.3.1 DoF

• 自由度（Degrees of Freedom, DoF）表示物体可独立变化的运动维度。

  • 三自由度（3DoF）一般只有旋转：绕 X 轴旋转；绕 Y 轴旋转；绕 Z 轴旋转。

  • 六自由度（6DoF）包含：

    • 三个平移：X、Y、Z；

    • 三个旋转。

3.3.2 Position, Orientation, Pose

• 位置（position）是三维坐标：p=(x,y,z)p=(x,y,z)p=(x,y,z)

• 朝向（orientation）描述物体如何旋转。

• 位姿（pose）是位置和朝向的组合：Pose=(position, orientation)Pose=(position,\ orientation)Pose=(position,orientation)

  • 但一个完整 pose 还必须包含两个隐含信息：
    PoseF(t)=(p,q) Pose_F(t)=(p,q)PoseF​(t)=(p,q)

    • (F)：它相对于哪个坐标系（frames）；

    • (t)：这个 pose 对应什么时间；

    • (p)：位置；

    • (q)：旋转。

3.4 Camera Tracking

3.4.1 IMU

• 惯性测量单元（Inertial Measurement Unit, IMU）通常包含：

  • 陀螺仪：测量角速度；

  • 加速度计：测量线性加速度相关信号。

• 头显定位通常融合 IMU 和摄像头信息。IMU 更新频率高，适合短时间运动估计，但积分会产生漂移；摄像头通过环境视觉特征提供几何约束，可以帮助纠正漂移。

• 现代头显通常采用VIO（视觉惯性里程计）或SLAM（同步定位与建图）进行 6DoF 位姿跟踪。

3.4.2 SLAM

• SLAM 同时完成 Localization（设备定位）和 Mapping（环境建图）。这里需要区分三个层级：

  • Tracking Map：SLAM 内部用于定位的环境特征地图，例如 3D feature points，主要服务于设备 pose estimation。

• Spatial Mesh：提供给应用的环境几何表面，例如墙、桌面、地面对应的三角网格，可用于碰撞、遮挡和空间交互。

• Scene Understanding：在几何信息上进一步加入语义，例如识别 floor、wall、table 等场景结构。

三者可能共享相同的底层传感器数据，但不是同一个输出。SLAM 本身主要解决几何与定位问题，不等于物体级语义理解。

3.4.3 Inside-Out & Outside-In

• Inside-out tracking：

  • 摄像头装在头显上；

  • 头显向外观察房间；

  • Quest 主要采用这种方式。

• Outside-in tracking：

  • 外部摄像头或基站观察头显/控制器；

  • 常用于专门的高精度 tracking 系统。

• 控制器 tracking 通常融合控制器 IMU 与头显摄像头观测。手部 tracking 则通常由摄像头图像经过手部检测、关键点估计和时序追踪，输出 wrist、palm 和手指关节的 pose。

4. Coordinate Frame

4.1 Coordinate System & Frame

• 坐标系（coordinate system）规定：

  • X、Y、Z 轴；
  • 轴的正方向；
  • 左手系或右手系；
  • 长度单位；
  • 旋转表示方式。

• 坐标框架（coordinate frame）包含：

  • 一个具体 origin；
  • 一组具体方向的轴。

• 两个 frame 可以使用同样的轴约定，但原点和朝向不同。

• Coordinate System 定义坐标表示的规则；Coordinate Frame 是这个坐标系统在空间中的一个具体实例，具有自己的原点和朝向。XR/Robotics 中通常更关心不同 Frame 之间的相对变换。

4.2 Local Space 与 World Space

• 局部空间（local space）表示相对于父节点的坐标。

• 世界空间（world space）表示相对于场景全局 frame 的坐标。

• 假设 Unity 中：

  XR Origin └── Head Camera

  • 那么

  Head Camera.localPose = head 相对于 XR Origin 的 pose Head Camera.worldPose = XR Origin.worldPose × Head Camera.localPose

  • 这就是 parent/child transform composition。

• XR Origin 是 Unity XR 场景中用于表示整个 XR 用户/设备系统的根坐标框架。Headset、Controller、Hand 等 tracked objects 通常作为其子对象，其 pose 由 XR tracking 系统更新。移动 XR Origin 可以整体改变用户在 Unity World 中的位置，而不会破坏头显和手部的局部 tracking。

  World Frame ↓ XR Origin Frame ↓ Head Frame ↓ Hand Frames

4.3 Transform

• 假设场景里有：培养皿、机械臂、桌子、摄像机、左手、一个虚拟按钮

  • 这些在 Unity 里通常都可以是一个GameObject（游戏对象/场景对象）。

  • 但 GameObject 自己其实很“空”，真正的功能来自它挂载的各种Component（组件）。例如：

    PetriDish GameObject ├── Transform: 它在哪里、朝向哪里、多大、父子关系是什么； ├── Mesh Renderer: 把培养皿画出来； ├── Collider: 让它能参与碰撞/交互判断； └── 自己写的 C# Script: 你自己定义它的行为

• Unity 的 Transform 是每个 GameObject 都有的空间组件，包含：

  • position；rotation；

    • transform.position/transform.rotation：相对于World Frame

    • transform.localPosition/transform.localRotation：相对于Parent Frame

  • scale——表示这个 GameObject 相对于原始大小放大或缩小多少。

    • 默认：scale = (1, 1, 1)——表示原始大小不变。

    • 如果：scale = (2, 2, 2)——表示 x、y、z 三个方向都放大 2 倍。

      • 例如原本培养皿直径是：10 cm
      • 设成：scale = (2,2,2)，视觉上就会变成：20 cm

    • 也可以只缩放某个方向：scale = (2, 1, 1)，x 方向 ×2，y 方向 ×1，z 方向 ×1；于是物体会被“横向拉长”。

  • parent/child relationship。

• Unity Transform 包含 position、rotation 和 scale，因为 Unity 允许对虚拟物体进行缩放。Robotics 中坐标系之间通常使用 Rigid Transform（刚体变换），只包含 translation 和 rotation，因为坐标变换只描述 frame 的位置和朝向，不应改变真实物体的尺寸。

• 旋转常用单位四元数（quaternion）表示。四元数用四个数表示三维旋转，避免欧拉角在某些姿态下出现万向节锁。需要注意：

  • 不同系统的四元数元素顺序可能不同；
  • (q) 和 (-q) 表示同一个旋转；
  • 四元数不能像普通位置向量一样随便交换坐标分量。

4.4 OpenXR Reference Space

• OpenXR Reference Space（参考空间）是 XR Runtime 定义的 tracking coordinate frame，用于表达头显、手柄等 tracked device 的 Pose。常见的 Reference Space 包括 VIEW、LOCAL 和 STAGE。
  • VIEW：随头部移动的视图坐标系，适合 head-locked 内容。
  • LOCAL：应用启动附近建立的局部稳定坐标系，用于一般 tracking。
  • STAGE：以真实地面/房间空间为基准的坐标系，适合 standing/room-scale XR。
• XR Origin 是 Unity 场景中的根节点，用于把 OpenXR Runtime 的 tracking space 映射到 Unity World Space。移动 XR Origin 不会改变真实头显的位置，而是改变整个 tracking space 在 Unity 世界中的位置。

4.5 Spatial Anchor

• 空间锚点（Spatial Anchor）是由 Runtime 追踪的、与现实环境位置关联的空间 frame。

  • Anchor 不是虚拟物体本身，而是：

    real-world-associated frame └── virtual GameObject

  • 当系统重新定位环境后，会重新估计 anchor 相对于当前 tracking space 的 pose。应用根据这个 pose 更新虚拟物体，所以物体看起来仍然固定在真实桌面上。

5. Runtime Pipeline

• Runtime Pipeline

  头显厂商提供的底层 XR 系统软件，负责把硬件能力统一提供给上层应用

  Runtime Pipeline解决：手在哪里？头在哪里？按键有没有按？画面怎么显示？

  属于底层设备与 tracking。

  [Quest Hardware] IMU + Tracking Cameras + Controllers + Hand Images ↓ [Quest Tracking System / XR Runtime] Sensor Fusion + VIO / SLAM ↓ Head / Hand / Controller poses Reference Spaces Input Actions Predicted Eye Views ↓ [Unity Application Process] XR Origin mapping Application state update Interaction logic Animation / physics / networking ↓ [Unity Rendering] Scene visibility Left-eye view + Right-eye view ↓ [Quest GPU] Render images into XR swapchain ↓ [Quest Runtime Compositor] Projection layers + UI layers + Passthrough Late pose correction / reprojection Lens distortion correction ↓ [Left / Right Display + Optics] ↓ Photons reach the eyes

5.1 Stereo Rendering, FoV, IPD

• Unity Camera 是虚拟摄像机，不是 Quest 上的物理 RGB 摄像头。

• 在 XR 中，通常一个 Unity Camera 概念会被 Runtime 和渲染管线展开成：

  • left-eye view；

  • right-eye view。

• 立体渲染（stereo rendering）让左右眼看到略有差异的图像，从而产生双目深度感。

• 视场角（Field of View, FoV）是眼睛能看到的角度范围。

• 瞳距（Interpupillary Distance, IPD）是左右眼瞳孔中心之间的距离。应用通常不应硬编码左右眼距离，而应使用 Runtime 提供的每眼 view pose 和 FoV。

5.2 Refresh & Frame Rate, Latency

• Refresh & Frame Rate

  • 刷新率（refresh rate）是显示器每秒刷新多少次。
  • 帧率（frame rate）是应用每秒实际生成多少帧，常用 Frames Per Second 表示。
  • 两者不一定相等：
    • display 可以 90 Hz 刷新；
    • Unity 可能只生成 72 帧；
    • Runtime 可能重复或重投影某些帧。

• 运动到光子延迟（motion-to-photon latency）表示：

  physical head motion → sensing → tracking → prediction → application → rendering → composition → display emission

  • 以上的总延迟
  • 这是 XR 舒适度的核心指标。90 Hz 对应约 11.1 ms 的显示周期，但这并不等于整个 motion-to-photon latency 恰好是 11.1 ms。

6. Interaction Pipeline

• 抓取手势

  真实手 ↓ Quest Hand Tracking ↓ XR Runtime ↓ 手指 joint pose + pinch state ↓ Unity ↓ Interaction System ↓ 判断： 手碰到培养皿 Collider + 用户 pinch ↓ Grab / Select Event ↓ 应用逻辑

6.1 交互形式

• 控制器输入（controller input）包括：button；trigger；thumbstick；controller pose。
• 手部 tracking 一般输出手部骨架的多个 joint pose。
• 手势（gesture）是在这些低层状态之上识别出的语义动作，例如 pinch 或 open hand。
• 射线交互（ray interaction）是从控制器、手或 gaze 发出一条虚拟射线，用于远距离选择。
• 直接交互（direct interaction）是手或控制器靠近并接触物体。
• 射线检测（raycast）是沿一条射线查询它与哪些几何体相交。
• 碰撞体（Collider）是 Unity 用于碰撞和空间查询的不可见几何形状。
• 刚体（Rigidbody）表示由 Unity physics 管理的位置、速度、质量、力和碰撞状态。
• 移动方式（locomotion）是用户在虚拟空间中移动的方法，例如物理行走、teleport 或连续移动。

6.2 Runtime 和 Intersection

XR Runtime（运行时）是连接 XR 硬件与应用的软件层，负责 tracking、设备输入、空间定位、pose prediction 和最终显示合成等底层功能。Runtime Pipeline 描述硬件感知到 XR 状态输出及显示的流程。

Interaction Pipeline 位于 Runtime 之上，利用 Runtime 提供的 head/hand/controller pose 和 input state，结合 Unity 中的 Collider、Raycast、Gesture 等机制，将低层输入解释为 Select、Grab、Teleport 等高层交互事件。

6.3 Unity XR Interaction Toolkit

• Interactor 表示发起交互的一方，例如手或控制器；

• Interactable 表示可以被交互的对象；

• Interaction Manager 负责匹配二者和管理 hover、select 等状态。

• XR Interaction Toolkit 是高层交互框架，不负责底层 tracking。

7. Spatial Understanding

7.1 Spatial Mesh

• 空间网格（spatial mesh）是对现实环境表面的三角网格近似。

• 例如桌面、墙和设备可能被表示为大量三角形。它比 plane 更细，但通常有噪声，并不等于精确 CAD 模型。

7.2 Plane Detection

• 平面检测（plane detection）寻找近似平坦的区域，例如：floor；wall；table surface。

• 它通常输出：plane pose、plane extent / boundary、optional semantic label、confidence

7.3 Scene Understanding

• 场景理解（scene understanding）把低层空间数据组织成更有意义的实体
  • 例：room：floor，wall，table，door，other volumes
• 在 Quest 的 Meta 工具栈中，MR Utility Kit 会在更低层的 Scene 能力上提供房间感知、空间查询和内容放置等高层工具

7.4 World-Locked 与 Head-Locked

• World-locked content：

  • pose 定义在 world、local、stage 或 anchor frame 中；
  • 用户转头时它不会跟着头走；
  • 看起来固定在现实或虚拟空间中。

• Head-locked content：

  • pose 定义在 view/head frame 中；
  • 用户转头时它跟随视野；
  • 适合小型状态提示，不适合大面积内容。

8. Unity

• Unity位于XR Runtime 之上，Application 逻辑之中，GPU rendering 之前

  • Unity 主要负责：
    • 表达应用的数字世界；
    • 管理对象和场景；
    • 执行 C# 应用逻辑；
    • 把 tracking pose 映射到虚拟对象；
    • 执行交互和应用 physics；
    • 准备左右眼渲染；
    • 与 Python、机器人和网络服务通信。
  • Unity 一般不负责：
    • Quest 底层 camera/IMU driver；
    • Quest 的核心 SLAM；
    • 最终 lens distortion；
    • 系统级 compositor；
    • 设备显示调度。

• Unity的核心概念

  概念	在 XR 中的含义
  Scene	一个可运行场景的数据集合，包括对象、灯光、XR Origin 和 UI
  GameObject	场景中的基本实体，本身主要是组件容器
  Component	赋予 GameObject 行为或数据的模块
  Transform	对象的 position、rotation、scale 和父子关系
  Camera	从哪个虚拟位置渲染场景；XR 中由 head tracking 驱动
  Prefab	可重复实例化的对象模板，例如机器人、按钮或抓取物体
  MonoBehaviour	用户编写的 C# Component 基类，类似带生命周期回调的对象
  Collider	用于碰撞和空间查询的形状
  Rigidbody	由 Unity physics 更新的动态刚体
  Update()	通常每个应用渲染帧调用一次
  FixedUpdate()	按固定 physics 时间步调用，不保证每个渲染帧恰好一次
  XR Origin	把设备 tracking space 放入 Unity world 的根节点
  Input System	Unity 的 action-based 输入映射系统

  • Unity physics 使用固定时间步；渲染帧和 physics step 是不同的 loop。

• 在典型 Unity XR 场景中，你通常不需要自己每帧“读取 head pose 再写 Camera”。XR provider 会自动驱动 Camera 的 local Transform：T_world_head = T_world_xrOrigin × T_xrOrigin_head

  • 你的应用主要决定T_world_xrOrigin和虚拟内容，而 Runtime 持续提供T_xrOrigin_head。

9. OpenXR, Unity XR, Meta XR

Unity 应用 ↓ OpenXR 标准 ↓ 不同 XR Runtime ├── Meta Quest ├── SteamVR └── 其他 OpenXR 设备

• OpenXR：Khronos 制定的跨平台 XR 标准，定义“应用应该用什么统一接口去访问头显、手柄、tracking、reference space 等”。它本身不是 Unity，也不是 Meta
• Unity XR：Unity 对各种 XR 平台提供的一套开发框架和插件体系。Unity 的 OpenXR Plug-in 就是把 Unity 的 XR 功能接到 OpenXR 标准接口上。
• Meta XR：Meta 针对 Quest 提供的 XR Runtime 和 Quest 特有能力，例如 passthrough、scene、anchor 等。Unity 里还可以通过 Meta 的 OpenXR 扩展包访问这些 Quest-specific features。Unity 官方的 Meta OpenXR 包本身就依赖 OpenXR Plug-in，并负责接入 Meta-specific OpenXR extensions。