第一次遇到空间错位时，我把问题归咎于“头显漂移”。房间没有动，定位边界也正常，但虚拟桌子每次启动都会顺时针偏一点：站在入口处看只差几厘米，走到房间另一端，误差已经足以让手柄穿过桌沿。
真正的问题并不在追踪精度，而在我把三个不同的坐标系当成了一个。
这类故障麻烦之处在于，它看起来很像随机漂移，实际上往往是稳定的系统误差。只要把坐标链拆开、用地面上的三个点做一次可复现标定，就能判断到底是原点、朝向、比例，还是运行时参考空间出了问题。
下面记录一套不绑定设备型号的做法。它适合展厅、教室、门店和小型大空间体验，也适合在 WebXR 原型阶段快速定位“为什么越走越歪”。
一、先别调参数：错位通常有四种形状
我会先让测试者依次站到房间中央和四个角，不动任何配置，只记录虚拟标记相对地面胶带的位置。误差的形状比误差的绝对值更有信息量。
| 现象 | 更可能的原因 | 第一检查项 |
|---|---|---|
| 所有位置都朝同一方向偏移，偏差近似相等 | 平移量错误 | 房间原点是否取错 |
| 离原点越远，横向误差越大 | 航向角错误 | “正前方”基准线是否可靠 |
| X、Z 两个方向误差都按距离同比增长 | 单位或比例错误 | 是否把厘米当成米 |
| 本次正常、重启后整体换了位置 | 参考空间重建 | 是否错误持久化了运行时原点 |
最容易误判的是第二种。假设朝向只错了 1°，在距原点 4 米的位置，横向误差约为：
4 × sin(1°) ≈ 0.07 米
也就是 7 厘米。入口附近很难察觉，房间尽头却已经明显错位。因此，“中央点对齐”不能证明空间已经标定正确。
二、坐标链：不要把 XR 原点当成房间原点
WebXR 的位姿来自某个XRReferenceSpace。常见运行时以米为单位、Y 轴向上，观察方向沿 -Z；但local-floor的原点由运行时建立，并不等于施工图中的房间原点，也不保证设备重启后仍对应同一块地砖。
应用真正需要的是这条变换链：
世界坐标 = 房间到世界的变换 × XR 到房间的标定变换 × XR 位姿
其中：
- XR 位姿由每一帧的
XRFrame提供； - XR 到房间的变换由现场标定得到；
- 房间到世界的变换由内容设计决定，例如把真实墙面映射到虚拟展墙。
把三者揉成一个“magic offset”虽然能暂时对齐某个点，但之后很难判断究竟是哪一层失效。
三、用三个地面点完成一次可验证标定
我在地面贴三个可重复找到的标记：
- A：房间原点；
- B：从 A 指向房间定义的“正前方”；
- C：位于侧边，只用于校验，不参与第一次拟合。
A 与 B 的距离尽量拉长。两点只相距 50 厘米时，1 厘米的落点误差会带来约 1.15° 的角度误差；两点相距 3 米时，同样的落点误差只对应约 0.19°。这比不断调小数点后的旋转参数有效得多。
标定流程如下：
- 请求
local-floor参考空间；如果设备不支持，再明确降级，而不是悄悄混用local。 - 让控制器或头显中的准星依次对准 A、B，采集各 30 帧。
- 对每组位置取中位数，减少手部抖动和偶发跳点的影响。
- 用 A 求平移，用 A→B 求水平面内的航向角。
- 把 C 代入变换，只计算残差；残差过大就拒绝保存本次标定。
这里刻意不让 C 参与第一次拟合。原因很简单：如果三个点都拿来“追着数据拟合”，一个贴歪的胶带也可能得到看似漂亮的结果；保留一个独立校验点，才能暴露采集错误。
四、核心代码：只解平移和航向角
对于地面平整的小空间，先解四自由度——X、Y、Z 平移加水平航向角——通常比直接上完整的六自由度矩阵更稳。下面的代码省略 UI，只保留计算部分。
const median = (values) => { const sorted = [...values].sort((a, b) => a - b); const mid = Math.floor(sorted.length / 2); return sorted.length % 2 ? sorted[mid] : (sorted[mid - 1] + sorted[mid]) / 2; }; const medianPoint = (samples) => ({ x: median(samples.map((p) => p.x)), y: median(samples.map((p) => p.y)), z: median(samples.map((p) => p.z)), }); const horizontalAngle = (from, to) => Math.atan2(to.x - from.x, -(to.z - from.z)); export function solveRoomCalibration({ xrA, xrB, roomA, roomB }) { const xrYaw = horizontalAngle(xrA, xrB); const roomYaw = horizontalAngle(roomA, roomB); const yaw = roomYaw - xrYaw; const cos = Math.cos(yaw); const sin = Math.sin(yaw); const rotatedA = { x: xrA.x * cos - xrA.z * sin, y: xrA.y, z: xrA.x * sin + xrA.z * cos, }; return { yaw, translation: { x: roomA.x - rotatedA.x, y: roomA.y - rotatedA.y, z: roomA.z - rotatedA.z, }, }; } export function applyCalibration(point, calibration) { const { yaw, translation: t } = calibration; const cos = Math.cos(yaw); const sin = Math.sin(yaw); return { x: point.x * cos - point.z * sin + t.x, y: point.y + t.y, z: point.x * sin + point.z * cos + t.z, }; }实际项目里，我还会把以下信息和结果一起保存：参考空间类型、标定版本、采集时间、A—B 实测距离、校验点残差。不要保存 Cookie、账号或设备序列号；这些信息对复现坐标问题没有帮助。
五、一个小数据集，足以识别大多数错误
以下数字是为了说明方法而构造的示例，不是某款设备的性能测试。房间坐标中，A 为(0, 0, 0)，B 为(0, 0, -3)，C 为(2, 0, -2)。
| 检查项 | 标定前 | 标定后 | 示例判定 |
|---|---|---|---|
| A 点平面误差 | 11.4 cm | 0.8 cm | 通过 |
| B 点平面误差 | 15.2 cm | 1.6 cm | 通过 |
| C 点平面误差 | 18.7 cm | 2.4 cm | 预警但可继续 |
| A—B 距离差 | 0.9% | 0.9% | 不应由刚体变换“修复” |
如果平移和旋转完成后，A、B 对齐而 C 仍偏差很大，需要检查的不是更多旋转参数，而是下面三件事：
- 物理测量是否准确；
- XR 运行时是否存在边界重建或短时追踪丢失；
- 内容资产是否在导出时发生了单位缩放。
刚体变换不能修复比例错误。试图给空间偷偷乘一个0.98，很可能让当前三个点更好看，却让虚拟物体尺寸失真。
六、验收不要只看“能不能对上”
我的验收表会固定测试路径，而不是让体验者随便走一圈：
- 冷启动应用，在 A、B、C 三点各停留 5 秒；
- 沿房间边缘完整走一圈，再回到 A；
- 摘下并重新戴上头显，复查三点；
- 完全退出会话后重进，确认系统要求重新标定或正确恢复；
- 遮挡部分追踪视野 2 秒，恢复后观察是否出现整体跳变。
阈值必须结合设备、场地和交互风险制定。对只展示信息的空间，5 厘米可能可接受；如果虚拟按钮需要贴合真实台面，2 厘米也可能太宽松。关键不是照搬某个数字，而是提前定义“超过多少必须阻止进入体验”。
我通常采用三档结果：
- 通过：所有校验点都在目标阈值内；
- 可用但需复核：没有越过安全阈值，但出现趋势性误差；
- 失败：越过安全阈值、参考空间改变，或数据不足。
“失败”必须让用户知道下一步做什么，例如“请重新对准 A、B 两点”，而不是只弹出一句“标定异常”。
七、最后得到的不是一组参数，而是一条证据链
空间标定最有价值的改进，不是把偏移从 7 厘米调到 2 厘米，而是把问题从“感觉有点歪”变成可定位、可复测的工程对象：
- 误差是否随距离增长？
- 重启后是参数失效，还是参考空间被重建？
- 第三个点能否独立验证前两个点算出的变换？
- 本次结果是否达到场景自己的安全阈值？
当这些问题都有记录时，换头显、换房间或换内容资产，都不需要从“再试着转一点”重新开始。
房间确实没有动。真正需要固定下来的，是房间、运行时和虚拟世界之间那条清楚的坐标链。