研究 on CloudLake

给 AI 装上一双能测距的眼睛

Tue, 20 Oct 2026 00:00:00 +0000

你戴着它，问一句「前面有什么」。

它需要回答的其实不是「前面有一个人」——而是「前面 0.8 米有一个人」。

这两句话对一个只会做目标检测的系统来说，差着一整个维度。

只有 2D 检测，是看不见「多远」的

YOLO 能给你一个框、一个类别、一个置信度。

1

person 0.89 [x1,y1,x2,y2]

但它不知道这个人在一米外还是五米外。

而这件事在真实场景里是致命的：

「前面有人」→ 你继续走
「前面 0.4 米有人」→ 你必须停

同一个检测结果，两种完全相反的行动。

所以我给这个系统加了两个东西：深度估计和激光雷达。

三层感知

整个系统的骨架是这样的：

层	干什么
① 输入	文本指令，或 Whisper 实时语音转写
② 调度	Orchestrator 把自然语言映射到一个视觉能力
③ 视觉	YOLOv8n 检测 / MiDaS 深度 / EasyOCR 文字
④ 标定	用 LiDAR 快照重标定深度尺度
⑤ 输出	`hazard_level` + 人话 message + 结构化 meta

对外是 FastAPI 的 MCP 接口：

1
2


POST /api/v1/mcp
{"text": "描述周围"}

返回里既有给人看的句子，也有给程序用的字段。

五个能力，带优先级

调度器不猜——它把指令映射到一个明确的 function：

1
2
3
4
5


"vision.ocr_read": "high" # 读文字
"vision.detect_objects": "medium" # 检测物体
"vision.distance_query": "medium" # 问距离
"vision.describe_scene": "medium" # 描述场景
"vision.check_hazards": "low" # 判断危险

check_hazards 优先级最低，因为它要调用前面全部能力才能回答——它是管线末端，不是入口。

意图分类有两路：

规则匹配（关键词、正则）—— 快、可预测
sklearn 模型（intent_sklearn.joblib，965 KB）—— 处理规则覆盖不到的说法

规则优先，模型兜底。

核心设计：LiDAR 只做标定，不做判定

这是整个项目里我最想讲的一个决定。

先说结论（这也是代码注释里的原话）：

基于视觉深度和 YOLO 距离统一评估危险，LiDAR 仅用于深度标定。

为什么不直接用雷达测距？

因为雷达虽然准，但它只有一条线。

forward_min_distance 是 ±30° 扇区内的最小距离——它告诉你「正前方最近的东西有多远」，但不告诉你是谁、有几个、在哪。

如果我拿这个数字直接判定危险，会有两个问题：

误报：地上一个 5 厘米的纸盒，距离 0.3 米 → 判定「危险」。但你可以直接跨过去。
漏报：右边 0.5 米有个台阶，不在 ±30° 扇区内 → 雷达看不到，可你会撞上。

雷达给的是标量，安全需要的是语义。

那怎么用雷达？

把它当标尺，不当裁判。

MiDaS 输出的是相对深度——它知道「这个人比那面墙近」，但不知道「近多少米」。所以：

1
2
3


1. 先做线性投影，把相对深度映射到一个先验区间 near=0.4m, far=8.0m
2. 再用 LiDAR 的 forward_min_distance 对这个投影做一次重标定
3. 如果雷达认为近，就动态放宽 YOLO 的置信度阈值（0.5 → 0.3）

第 3 步是个很实用的联动：雷达说近，就宁可多报一点。因为近距离下漏检的代价，远大于误检。

上图是 MiDaS 的输出叠加——颜色代表距离（暖色近、冷色远）。可以看出它能把空间关系画得很清楚，但具体数值需要标尺。

危险分级

最终判定基于两条证据：

1
2
3


if nearest_box_dist < 0.5: hazard_level = "danger" # 有物体且极近
elif nearest_box_dist < 1.0: hazard_level = "warning" # 有物体但还远
else: hazard_level = "safe"

没有检测到物体时，退回到视觉深度给出的前方最小距离。

所以：

有语义 → 用「谁 + 多远」
无语义 → 用「最近的表面多远」

两条路兜底，不会出现沉默失败。

没有硬件也能跑：Stub 后端

这套系统依赖摄像头、激光雷达、YOLO 权重、MiDaS 权重。换一台机器就全没了。

所以每个后端都有两套实现：

真实后端	Stub 后端
YOLOv8n	固定框 + 固定距离
MiDaS	合成深度图
EasyOCR	固定文本
LiDAR	模拟快照

配置文件一行就能切：

1

SIMULATION_MODE = 1

这不是为了偷懒，是为了让测试能跑。 有了 Stub，CI 里不需要 GPU、不需要串口、不需要摄像头，全套流程照样能验证。

测试：让「软融合」这个说法可被验证

三个测试文件，分别守一件事：

测试	在验证什么
`test_p0_smoke`	API 契约、分阶段耗时、雷达快照新鲜度
`test_p1_lidar_soft_fusion`	紧急闸门、自适应阈值
`test_p2_depth_metadata`	深度可用/缺失时的元数据与降级

其中最有价值的是 P1：

1
2


assert result.meta.get("hazard_level") == "high"
assert result.meta.get("forward_min_distance") == pytest.approx(0.4)

1

assert thresholds.get("yolo_conf_threshold") == pytest.approx(0.3)

这两条断言把「雷达软融合」从一个形容词变成了一个可验证的行为：

雷达报 0.4 米 → 危险等级必须是 high
雷达报近 → 置信度阈值必须降到 0.3

如果哪天我重构代码把这个逻辑弄丢了，测试会立刻失败。

P2 守的是另一件事——深度失败时必须明确降级，而不是静默给出错误的距离：

1
2


assert result.meta.get("depth_error") == "midas_missing"
assert all(box.dist is None for box in result.objects)

宁可承认「我不知道多远」，也不编一个数字。

为什么这个项目值得做

因为「AI 能看见」这件事，大多数人理解成「能识别」。

但识别和感知是两件事：

识别	感知
这是什么	这是什么 + 多远 + 算不算危险
一张图	连续的一段时间
给人看	给行动用

一个只会识别的系统，永远只能当玩具。

要让它能驱动机器人、能辅助视障者、能放进 XR 头显——它必须先知道距离。

技术栈

Python · FastAPI · YOLOv8n · MiDaS · EasyOCR · Whisper · RPLIDAR A1 · scikit-learn · pytest

这个项目最后教会我的，不是怎么调深度模型。

是「多一个传感器」不等于「多一份信任」——多一个传感器，意味着你要更清楚地决定该在什么时候听它的。

对着杯子按一下扳机：把生成式 3D 接进 XR 运行时

Mon, 19 Oct 2026 00:00:00 +0000

举着 Quest，对着桌上的杯子按下扳机。

几十秒后，一个可以拿在手里转的杯子出现在你面前。

这就是这个项目要做的事：把生成式 3D 接进 XR 运行时。

也正因为"接进"两个字，它比听起来难得多。

为什么难

把 2D 生成接进网页，你只要拿回一张图，塞进一个 image 标签就行。

但把 3D 生成接进 XR，你要面对三个运行时约束：

① 材质不能在运行时可靠重建

生成式管线经常把材质烘进 shader graph。而在 XR 渲染管线里，动态加载的 shader graph 无法可靠还原——它依赖编辑器期的编译结果。

② 生成模型的坐标是不可信的

自动生成的模型，pivot 位置随机、坐标原点不规则、内部结构千奇百怪。直接拿它的 pivot 去转，你会看到模型一边转一边漂。

③ 尺度完全不可控

有的模型生成出来像指甲盖，有的大得像房子。

这三个问题都不是"模型生成得不好"——是生成结果和 XR 运行时之间的接口没有对齐。

系统的三个部分

整个系统分三块：

组件	跑在哪	职责
XR 运行时	Meta Quest 一体机（Unity）	透视取景、交互控制、运行时装配与渲染
服务端编排	轻量控制器	工作流协调、状态管理、资产路由
生成管线	ComfyUI + Hunyuan3D	所有计算密集的生成任务

通信走 REST：异步上传、状态轮询、资产拉取。

整个系统完全在运行时工作——不需要任何离线预处理或编辑器期资产准备。这是刻意的：真实部署的 XR 应用就是这么跑的。

决策一：在生成端就把几何和纹理拆开

这是整个系统最核心的一条。

常规做法是生成一个带材质的整体 GLB，丢进引擎直接用。

我们没这么做。

ComfyUI 工作流最后输出两个独立的东西：

一个只含几何的 GLB 网格
一张纹理图片

然后在 XR 运行时里，显式创建一个原生渲染材质，把纹理绑到对应的输入通道上。

为什么

因为这样绕过了隐式的 shader 编译机制。

一旦材质是烘在资产里的，你就把控制权交给了资产生成方。而生成方给的材质，在 XR 运行时里未必能加载、未必能编译、也未必要得。

拆开之后，材质绑定变成一个确定性的、你可以完全控制的步骤。

一句话：牺牲了"资产自包含"的便利，换来了运行时行为的确定性。

决策二：运行时显式装配

生成结果不会直接扔进场景。

系统走一条显式装配流程：

收到两个独立资产（GLB + 纹理）
实例化原生材质、绑定纹理
挂到转盘锚上（下一节）
自动归一化：用包围盒估算空间尺寸，算出一个统一缩放系数，让模型落进一个预设的"感知尺寸区间"
挂到更高层的空间根节点，成为可交互的 XR 对象

第 4 步解决的就是"有的像指甲盖有的像房子"。

而且这个归一化是在运行时算的——不需要人工调、不需要离线预处理。

决策三：转盘锚（Turntable Anchor）

这是解决"pivot 不可信"的答案。

思路很干脆：不去修正模型的 pivot，而是把它挂在一个锚下面。

模型自身的局部变换完全不动
所有关于"呈现"的变换——旋转、漂浮、缩放——全部作用在锚上

数学上就是：

1

最终世界变换 T = T_a ∘ T_m

其中 T_m 是模型的局部变换（不动），T_a 是锚的变换（动态更新）。

为什么这比"修 pivot"好

因为旋转轴只在世界空间里定义，与模型内部几何无关。

于是：

模型只会原地震转，不会一边转一边漂
不需要依赖任何几何启发式（比如"用包围盒中心当 pivot"——对不对称模型经常算错）
缩放、漂浮、透视/虚拟场景切换，全部在锚这一层统一处理

与其去猜一个结构不可信的对象"中心在哪"，不如给它一个外部坐标系。

一个很具体的设计问题：什么时候该阻塞用户输入

这个问题看着小，但处理不好会直接打崩服务端。

场景：用户按下扳机触发取景。

问题：什么时候禁止再次触发？

如果等到服务端响应才阻塞——那么在这段时间窗口里，用户可以连续触发多次取景。每一次都会向 ComfyUI 发一个新请求，任务队列直接被压垮。

更麻烦的是输入抖动：一次物理按键，可能产生多个输入事件。这会让系统平白提交好几个重复的生成任务，烧掉大量算力。

解法

在第一个取景命令触发的瞬间就阻塞输入。

然后在上传完成并拿到服务端响应时释放——包括失败和超时的情况。

正常流程下这个阻塞窗口很短，用户基本感知不到。而如果生成成功，阻塞会一直保持到整个工作流结束。

另外还加了帧缓冲与丢弃机制，避免网络延迟导致的错误决策。

这个例子的价值在于：它不是一个算法问题，是一个时序问题。 而时序问题只能靠想清楚状态机来解决。

生成管线

工作流搭在 ComfyUI 里，核心生成模型是 Hunyuan3D-dit-v2.0。

几个关键阶段：

阶段	做什么
输入预处理	把透视 ROI 图缩放到固定方形分辨率
去背景	剥离环境，得到干净的目标
几何生成（GenerateMesh）	图像 → 中间隐表示 → 解码出三维表面
网格后处理	修整产物
去光照（Delighting）	把原图的光照信息剥掉，避免"烤"进纹理
多视角渲染	用于纹理采样
多视角纹理采样 + UV 烘焙	把各视角的颜色烘到统一 UV 上

去光照这一步很容易被忽略，但很关键。 如果不去，原图里的阴影和高光会被当成材质的一部分烘进去，模型换个光照就露馅。

实测结果

系统在 Meta Quest 一体机上完整跑通。

指标	实测
端到端延迟（取景 → 可视化）	数十秒，取决于管线复杂度和服务端负载
连续多次生成	稳定，无持久性失败或不可恢复状态
失败/超时	正确释放输入阻塞、回到 idle，无需重启应用
旋转与漂浮动画	在不同模型间保持稳定，无轨道运动或漂移
XR 交互	生成期间取景/上传被门控，但视角操作仍然响应

一个诚实的说明

这个延迟不满足严格的实时约束。

“近实时"在这里指的是：通过异步执行和视觉反馈，让用户在等待期间保持参与感，而不是"几十秒内出结果”。

这个边界我写进了论文，也写在这里。

这个项目真正学到的东西

回头看，最值钱的不是"跑通了 Hunyuan3D"。

而是这三个判断：

接口比模型重要。 生成质量再好，如果和运行时的接口对不齐，也用不了。
不可信的东西，给它一个外部参照。 pivot 不可信就给锚，尺度不可控就归一化。
先想时序，再写代码。 输入阻塞那个问题，想清楚了只有十行代码；没想清楚会让服务端崩溃。

技术栈

Unity · Meta Quest · OpenXR · C# · ComfyUI · Hunyuan3D-dit-v2.0 · Python / Flask · REST 异步编排

论文：A System for Near Real-Time Generation and Runtime Visualization of Generative 3D Models in XR Environments（IEEE 会议格式）

最后一句是我写在论文里的判断：

这套系统的价值不在于生成得多好，而在于它把一条不可控的生成管线，接上了一个必须可控的运行时。