0. 简介

LightNav-0 面向指令跟随、目标搜索和动态跟随，研究的是视觉语言模型如何把看到的场景转成机器人能够执行的运动。它基于 Qwen3-VL-4B，先预测可通行位置与目标位置，再用三个残差量化 token 表示十个未来平面路点，将视觉理解与不同机器人的控制接口连起来。论文报告同一检查点覆盖十项导航仿真设置，公开仓库也提供 MicroDuck 双足机器人的 MuJoCo 演示。下面结合论文、固定版本代码和实际部署，分析空间指向、历史压缩与轨迹执行的关系，并记录小鸭子的操作方法和测试边界。
最近受到优刻得的使用邀请，正好解决了我在大模型和具身智能行业对GPU的使用需求。目前相关内容已经在官网中可以直接安装使用了LightNav-0自动生成项目中了。

1. 原理

1.1 导航任务与单目画面的轨迹接口

机器人接到“转身，走向电视”时，至少要解决目标定位、可行方向、运动尺度和连续控制四件事。LightNav-0 把前三件事统一为自回归 token 生成：输入自然语言目标与带时间信息的第一人称 RGB 历史，输出两个空间指向 token 和三个动作 token。动作 token 解码为十个包含前向距离、侧向距离和朝向的路点，随后交给执行层。共享的是视觉到轨迹的策略，各机器人的电机控制仍由各自的低层策略完成，因此跨形态泛化不等于用同一组关节角驱动所有机器人。

进一步看，模型没有为指令跟随、物体搜索和动态跟随各自增加预测头，而是在原有语言输出头上扩展指向与动作词表。任务意图来自指令和监督样本，导航输出仍遵循相同结构；换句话说，语言模型“说出的句子”具有明确的几何语法。这里的关键是把空间意图和执行轨迹同时放进模型能训练、能计算概率的表示中，而不是仅靠提示词要求普通聊天模型直接输出速度。下式中的 $a_t$、$o_t$ 是两个指向网格编号，$k_{\ell ,t}$ 是第 $\ell$ 层动作码本的编号。

$${\mathbf{y}}_t=[⟨{\mathrm{apos}}_{a_t}⟩,⟨{\mathrm{opos}}_{o_t}⟩,⟨{act\_L0}_{k_{0,t}}⟩,⟨{act\_L1}_{k_{1,t}}⟩,⟨{act\_L2}_{k_{2,t}}⟩].$$

1.2 双通道指向连接目标与可通行空间

Affordance point（APOS） 表示当前能走向的自由空间或局部落点，Object point（OPOS） 表示指令所指的物体或目标位置。两者可以不同：电视可能位于柜子上方，而机器人真正要接近的是电视前方的地面。将这两个位置分别预测，使“目标在哪里”和“现在往哪走”获得不同监督，又通过因果注意力共同影响后续动作。它也提供了可观察的中间结果，便于判断失败来自目标识别、通行方向还是执行环节，但图像中的点本身不构成碰撞保证。

直觉理解：在商场找电梯时，手指可以指向远处电梯标志，脚步却要先走向眼前通道。OPOS 像标志的位置，APOS 像下一段通道的入口；把两者分开，机器人就不必把目标像素当成可以直接穿过去的路线。

论文将归一化坐标 $(u,v)$ 映射到二维网格，用一个编号表示一个位置，下式给出零起索引的概念表达。代码使用 $48\times 27$ 的网格，并把有效位置编号整体加一，把零留给无有效位置或目标不可见的状态；APOS 另有左转、右转和停止保留编号。论文公式与代码的编号起点不同，这一处偏移会影响所有 token 的解释，因此调试时必须与检查点词表一致。以下节选来自 vln_utils.py，没有引入相机内参或深度。

$$r=\min (H_g-1,\lfloor H_{g}v\rfloor ),c=\min (W_g-1,\lfloor W_{g}u\rfloor ),i=r{W}_g+c.$$

# src/lightnav/vln_utils.py
def encode_point_pixel(u: float, v: float, width: float, height: float) -> int:
    """(u, v) pixel -> fine-grid point id (1..1296); clamps to the edge cell."""
    col = int(min(max(float(u) / max(float(width), 1.0), 0.0), 0.999999) * POINT_GRID_W)
    row = int(min(max(float(v) / max(float(height), 1.0), 0.0), 0.999999) * POINT_GRID_H)
    return 1 + row * POINT_GRID_W + col

这段实现先按画面宽高归一化坐标，再限制在网格有效范围，最后按行展开编号，避免落在最右或最下边界的点越界。反向解码取对应单元的中心，因此指向精度受到网格离散化限制，不能把标记点当成精确三维测量。进一步看，这种图像平面的公共表示适合复用视觉定位训练，真正的米制精度则由后面的轨迹码本提供；两类输出承担不同职责，也解释了为何模型需要同时学习指向监督和轨迹监督。

1.3 历史压缩保留近处细节与远期线索

只看当前画面容易忘记刚经过的路口，把全部历史原尺寸送入模型又会不断增加计算量。论文用时间感知视觉历史压缩描述这个取舍：帧越旧，采样越稀疏，空间池化越强；时间戳则保留采样后帧之间的真实时间关系。下式中的 $\Delta T_i$ 是第 $i$ 帧距当前时刻的时间，${\tau }_s$、${\tau }_p$ 分别控制时间采样和空间压缩的衰减速度，${\mathcal{G}}_s$ 是步长为 $s$ 的网格池化。它表达的是分配记忆预算的原则，不应直接当成发布代码逐帧执行的公式。

f s ( i ) = f s max ⁡ exp ⁡ ( − Δ T i / τ s ) , s i = max ⁡ { 1 , ⌊ exp ⁡ ( Δ T i / τ p ) ⌋ } , V ~ i = G s i ( V i ) . f_s(i)=f_s^{\max}\exp(-\Delta T_i/\tau_s),\qquad s_i=\max\{1,\lfloor\exp(\Delta T_i/\tau_p)\rfloor\},\qquad \widetilde{\mathbf V}_i=\mathcal G_{s_i}(\mathbf V_i). fs​(i)=fsmax​exp(−ΔTi​/τs​),si​=max{1,⌊exp(ΔTi​/τp​)⌋},V i​=Gsi​​(Vi​).

直觉理解：人记路时通常记得眼前台阶的细节，较久以前经过的大厅只留轮廓，出发点则保留一个锚点。历史压缩类似给相册分配位置：近期照片密集保留，旧照片挑选代表画面，不能把所有照片同时缩成一样模糊的缩略图。

当前检查点的 eval_config.json 采用分层 SlowFast，current 层保留最近两帧并使用池化系数一，fast 层覆盖帧龄二到三十三，mid 层按相邻帧对稀疏采样，long 层以固定帧对预算覆盖更长历史，anchor 层保留开头两帧。帧龄按历史帧索引计算，采样帧率配置为每秒四帧。代码在 slowfast.py 统一组织训练和推理的分段，并保证每段帧数为偶数，符合视觉时间片配对要求。

这里要厘清论文设计与当前发布入口的另一处边界：检查点实际使用 $256\times 448$ 的固定图像尺寸、视觉编码后的池化和相对时间戳，native_resolution=false。代码遇到检查点要求原生可变分辨率时会明确拒绝，而非自动采用论文列出的所有像素预算。因此本次部署沿用检查点的配置，不能因为论文讨论了原生分辨率，就声称当前演示正在按该方式运行。配置文件决定实际输入契约，论文则说明设计动机与实验范围。

1.4 三个残差码本表示十个路点

直接把三十个连续数值写成文本，生成长度、数值格式和几何误差都不易控制；只用一个有限码本，又容易丢失轨迹细节。LightNav-0 使用残差向量量化（RVQ）：第一级选择粗轨迹，第二级修正第一级留下的误差，第三级继续修正剩余误差。每级码本有二百五十六项，三层索引只需要三个动作 token，却可以组合出 $256^3$ 种编码。组合数量不等于所有组合都是合理轨迹，实际表现仍由码本覆盖范围和模型预测分布决定。

令 ${\mathbf{r}}^{(0)}=\mathbf{z}$ 表示待量化的轨迹特征，${\mathbf{e}}_k^{(\ell )}$ 是第 $\ell$ 层的第 $k$ 个码字，残差拟合按下式逐层进行。距离 $d_J$ 在拟合时考虑轨迹的几何权重，避免位置和转向量纲不同导致某一项支配聚类；论文也以平均位移误差与累计朝向误差的组合衡量轨迹。直观理解是，码本并非把坐标简单四舍五入，而是在整段运动形状上压缩，因此需要按实际轨迹空间检验压缩误差。

$$k_{\ell }=\arg \underset{k}{\min }{d}_J({\mathbf{r}}^{(\ell )},{\mathbf{e}}_k^{(\ell )}),{\mathbf{r}}^{(\ell +1)}={\mathbf{r}}^{(\ell )}-{\mathbf{e}}_{k_{\ell }}^{(\ell )},{\hat{\mathbf{z}}}^{(L)}=\sum _{\ell =0}^{L-1}{\mathbf{e}}_{k_{\ell }}^{(\ell )}.$$

难点提示：量化过程像先用一张粗地图找到街区，再用第二张图修正到街道，最后补上门口的位置。后两层描述的是上一层的偏差，不能分别把三层当成三条独立路线，也不能把三个 token 理解成仅有三步运动。

发布代码的重建还要撤销 Jacobian 特征加权，再按十个三维增量重排，并按表示类型决定是否做平面位姿复合。以下节选来自 traj_vocab.py，展示了解码的关键几步。论文讨论非空 RVQ 前缀也能得到粗轨迹，但当前解码器要求传入全部层的编号，服务还会抬高生成长度以容纳完整输出；直接降低 max_new_tokens 并不能启用论文中的一层或两层执行。

# src/lightnav/traj_vocab.py — RVQBundle.decode_waypoints 内部
        if len(codes) != len(self.codebooks):
            raise ValueError(f"got {len(codes)} codes, expected {len(self.codebooks)} levels")
        recon = np.zeros(self.codebooks[0].shape[1], dtype=np.float32)
        for lvl, code in enumerate(codes):
            recon += self.codebooks[lvl][int(code)]
        feat = (recon / self.jacobian_weights).reshape(self.horizon, 3)
        if self.representation == "se2_diff":
            return np.ascontiguousarray(compose_to_abs(feat[None])[0], dtype=np.float32)
        return np.ascontiguousarray(feat, dtype=np.float32)  # ego_abs

1.5 平面位姿复合恢复连续路线

$\mathrm{SE}(2)$ 描述平面中的位置和朝向，其关键在于旋转会改变下一步位移的坐标方向。若一段增量是在前一个路点的局部坐标系中定义，连续转弯时不能直接把所有横向和纵向位移相加，而应先用当前累计朝向旋转这一小步，再更新位置与角度。下式中 $(x_j,y_j,{\theta }_j)$ 是累计位姿，$(\Delta x_j,\Delta y_j,\Delta {\theta }_j)$ 是局部增量。这个运算把紧凑的动作编码恢复为控制器能够跟踪的几何路线，且始终以本段起点为参考。

$$\begin{array}{rl}{x}_j& =x_{j-1}+\cos {\theta }_{j-1}\Delta x_j-\sin {\theta }_{j-1}\Delta y_j,\\ y_j& =y_{j-1}+\sin {\theta }_{j-1}\Delta x_j+\cos {\theta }_{j-1}\Delta y_j,\\ {\theta }_j& =\mathrm{wrap}({\theta }_{j-1}+\Delta {\theta }_j).\end{array}$$

直觉理解：先向前走一步、左转、再向前走一步，第二个“前方”已经转了方向。位姿复合像拿着随身体旋转的小指南针走路，记录每步时必须转换到同一个起点坐标系，才不会把弯路错误画成直线。

对应的 compose_to_abs 使用双精度累计，再返回单精度数组，避免多步累积时过早引入舍入误差。下面是它的循环体，th 为进入当前小步前的累计角度，更新朝向前先计算位移旋转。这里的关键是动作解码产生路点而非电机命令：同一条相对路线可以被轮式、足式或其他执行层消费，具体速度、动力学约束和控制周期仍需要由执行端解释。

# src/lightnav/traj_vocab.py — compose_to_abs 内部
    for j in range(H):
        dx, dy, dth = deltas[..., j, 0], deltas[..., j, 1], deltas[..., j, 2]
        cos_t, sin_t = np.cos(th), np.sin(th)
        x = x + cos_t * dx - sin_t * dy
        y = y + sin_t * dx + cos_t * dy
        th = wrap_to_pi(th + dth)
        out[..., j, 0] = x
        out[..., j, 1] = y
        out[..., j, 2] = th
    return out.astype(np.float32)

1.6 统一监督与在线强化学习

训练分为 ER 中训练、导航监督微调和在线强化学习三个阶段。ER 先强化空间关系、指向、视频理解与可操作区域判断，导航阶段再让这些能力对应到双指向加轨迹的输出格式，并保留一部分视觉问答样本；DAgger 通过收集策略自己走到的状态，缓解只模仿专家路线时的分布偏差。各类样本共享因果交叉熵目标，下式中的 $\mathcal{M}$ 是需要监督的输出位置，$\mathbf{x}$ 为输入上下文。统一的是预测接口与损失形式，各数据源的语义和采样比例仍经过专门设计。

$${\mathcal{L}}_{\mathrm{CE}}=-\sum _{j\in \mathcal{M}}\log p_{\theta }(y_j\mid \mathbf{x},y_{<j}).$$

进一步看，动作采用离散 token 后，策略梯度需要的输出概率可以直接由语言模型给出，无需为连续生成过程另造概率代理。论文的 GRPO 对同一起点采样多条完整路线，用组内标准化后的终局奖励作优势，再进行带裁剪和参考策略约束的更新。这里要区分训练方案和部署依赖：本文解释该接口如何支持强化学习，本次使用发布检查点推理，没有重新训练，也没有复现训练阶段的全部采样与奖励系统。对于单次仿真失败，应先检查输入、输出与控制契约，不能直接归因于缺少训练。

1.7 MPC 在图像采集时刻对齐路线

模型处理一帧图像的过程中，机器人可能已经移动，因此返回的相对路线必须结合拍摄时刻的位姿转换到世界坐标，再从当前位置重新计算跟踪控制。若直接用收到回复时的位姿作为路线起点，相当于把整条路线随延迟向前或向侧面错移。仓库在 mpc.py 实现该坐标变换，并通过十赫兹控制循环、五步优化窗口和 CasADi/IPOPT 求解平面运动指令。里程计在这里用于执行对齐，不属于高层模型的视觉输入。

核心问题在于，路点预测和低层跟踪的时间尺度不同：前者决定未来一段要去哪里，后者持续根据当前状态调整线速度与角速度。MicroDuck 执行端又会把命令限幅到约 $\pm 0.30m/s$、$\pm 1.50rad/s$，以匹配步态策略能力。因此控制器中的通用速度上限不等于小鸭子的最终速度。代码还对小非零线速度做稳定步行区间处理，停止死区则保持零；这意味着观察控制台时要同时看 MPC 请求和机器人后端实际接受的命令。

1.8 小鸭子的六十一维观测与十四维动作

MicroDuck 的动作链条是“视觉路线—平面速度—关节目标—物理接触”。它使用 Pollen Robotics 发布的 ONNX 步态策略，每次输入六十一维观测，其中包含三维角速度、三维重力方向、十四维关节位置偏差、十四维关节速度、十四维上一时刻动作和十三维命令向量；输出十四维关节动作，再按默认姿态和动作缩放转换为位置执行器目标。LightNav 负责导航，步态策略负责站稳和走路，这两部分在工程上各有自己的输入输出检查，不能因为外观看起来像小鸭子就忽略关节顺序和归一化元数据。

以下节选来自 microduck.py，展示了每次步态推理和控制目标写入。ONNX 以五十赫兹更新，物理步长为 $0.005\mathrm{s}$，头部相机提供导航画面，机身位姿提供跟踪反馈。程序在启动时核对观测尺寸、输出尺寸、关节名称、默认角度和缩放元数据，运行时继续检查数值有限性；随意转换的策略文件即使能被 ONNX 读取，也未必满足这一机器人契约。

# mujoco_demo/vln_mujoco/robots/microduck.py
    def step(self) -> None:
        outputs = self.session.run(
            [self.output_name],
            {self.input_name: self.observation().reshape(1, 61)},
        )
        action = np.asarray(outputs[0], dtype=np.float32)
        if action.shape != (1, 14) or not np.isfinite(action).all():
            raise RuntimeError("MicroDuck walking policy returned invalid actions")
        self.last_action[:] = action[0]
        self.data.ctrl[:] = self.default_pose + self.last_action * self.action_scale

1.9 方法位置与可观察的失败边界

把 LightNav-0 放回相关工作中，可以看到动作表示和控制分工的演化。NaVid 将视频视觉语言模型用于单目导航，StreamVLN 进一步关注流式历史处理，DualVLN 则采用慢规划与快执行的双系统结构。LightNav-0 的特点在于用原有语言输出头同时产生空间指向和压缩轨迹，减少专用预测头，但系统仍需要历史组织、解码器与执行层。下表概括论文相关工作中的主要差异，不用于在不同感知条件、数据划分或计算预算下直接比较所有指标。

方法	高层输入与推理组织	动作接口或执行分工
NaVid	单目视频与语言目标	用语言形式预测离散导航动作
StreamVLN	流式视觉历史与 SlowFast 上下文	强调长程历史和在线推理效率
DualVLN	慢速空间规划与快速局部策略	像素目标交给独立轨迹执行策略
LightNav-0	单一视觉语言骨干与双通道指向	三个 RVQ token 解码十个路点，再由低层执行

最后看交互闭环，单 token 解码速度、单次预测延迟和任务完成时间是三种指标，论文的约四毫秒每 token 不能直接换算成小鸭子每秒完成多少次控制。画面采集、历史处理、视觉编码、序列预填充、输出解码、通信与物理执行都会影响观察到的行为。当前服务响应异常时，MPC 可能继续跟踪上一段路径，三百五十毫秒的手动命令看门狗也不代表模型失联就立即停车。测试时应联合检查新预测序号、指向点、路点、位姿与停止状态，再判断链条在哪一环失效。

2. 安装

2.1 安装推理与仿真依赖

下面是本次实际执行的两条核心安装命令。推理包采用可编辑安装，便于与固定源码对应；仿真使用仓库自带的 uv.lock，并显式启用提供 ONNX Runtime 的 microduck 可选依赖。这里的关键是，--locked 只约束仿真项目，根项目采用它自己的依赖声明，完整安装版本另存为交付包中的环境清单。已经部署好的机器直接使用启动脚本即可，不需要重新创建环境、重复下载权重或再次执行这一节。

/usr/local/miniconda3/envs/lightnav/bin/uv pip install --no-cache \
  --python /usr/local/miniconda3/envs/lightnav/bin/python \
  -e '/workspace/lightnav-deploy/LightNav-0[vllm,video]'

/usr/local/miniconda3/envs/lightnav/bin/uv sync \
  --project /workspace/lightnav-deploy/LightNav-0/mujoco_demo \
  --python /usr/local/miniconda3/envs/lightnav/bin/python \
  --extra microduck --locked --no-cache

MicroDuck 的机器人模型和网格位于 microduck_rl 目录，步态策略放在 microduck_policies/alpha_walking.onnx，两者都保持上游文件布局。主机首次启动时缺少 libEGL.so.1，实际修复采用下载 Ubuntu 对应的接口库并解包到 runtime-libs，由启动脚本设置局部搜索路径，随后双视角渲染恢复正常。没有通过跳过版本检查来处理启动问题；项目对 vLLM 私有接口的依赖决定了随意换版本可能直接破坏推理，环境可用性应由真实启动和输出验证。

2.3 启动、就绪和网页连接

模型服务选择 --task vln，因为演示要执行自然语言导航指令；默认的 tracking 对应目标跟随提示，不应混用。服务从 checkpoints/LightNav-0 加载权重，执行一次真实预热后才写入 run/model.ready 并开放端口，启动耗时不能用页面是否可访问来判断。仿真进程则加载 MicroDuck 的碰撞模型和步态策略，通过内部 WebSocket 连接模型。两者都监听 127.0.0.1，新增的 18088 鉴权代理提供公网访问。网页中的模型地址仍填写远端进程所使用的 ws://127.0.0.1:8050，浏览器的控制连接则自动使用同域名 WSS。

本实例直接访问 https://18088-cpod-1x20cvodizxr.pod.compshare.cn/。当前实例登录账号为 lightnav，密码为 GCf8XbxFk9-cShFd_WlCgKJ_HLFNmi9G。

cd /workspace/lightnav-deploy
source scripts/activate.sh
python scripts/manage.py start
python scripts/manage.py status

自动启动入口已经安装在 /start.d/40-lightnav.sh。脚本激活现有 lightnav 环境，启动模型与仿真，检查鉴权入口，并等待真实预热和相机就绪；防重复锁和进程启动标识避免重复加载。现有 Supervisor 的 /etc/supervisor/conf.d/lightnav-autostart.conf 在开机执行该入口，lightnav-web.conf 负责持续监管公网代理。可以手动重复执行以下命令，日志写入 logs/autostart.log：

bash /start.d/40-lightnav.sh
supervisorctl status lightnav-web
/usr/local/miniconda3/envs/lightnav/bin/python /workspace/lightnav-deploy/scripts/manage.py status

已验证配置载入、实际启动和重复执行后模型及仿真 PID 保持不变。启动入口就绪后正常退出，因此 Supervisor 的 lightnav-start 显示 EXITED 属于预期；公网代理 lightnav-web 应显示 RUNNING。本次没有重启整台机器验证开机流程。

这里要区分两个独立就绪条件：model 就绪表示完整推理路径已经通过预热，simulator 就绪表示机器人模型、物理循环和网页接口已经运行。控制台打开后，先确认 MicroDuck 的第一、第三人称画面，再输入目标指令并点击 Start VLN。真正连通后应同时出现非零延迟、持续更新的预测序号、十个轨迹路点和实际位姿变化；只看到 WASD 能驱动小鸭子，说明仿真和步态控制可用，尚不足以证明语言导航成功。

# 可选的 SSH 访问方式：在本地终端执行并保持连接。
ssh -N -p 24296 \
  -L 127.0.0.1:18088:127.0.0.1:8088 \
  root@cpod-1x20cvodizxr.podtcp.compshare.cn
# 浏览器打开 http://127.0.0.1:18088

2.4 日常使用和停止

演示中的 Take control 用于取得当前页面的手动控制权，WASD 控制前后移动和转向，空格或 STOP 将速度指令归零，RESET 恢复初始状态并取消自动导航。自动任务结束后可保留模型与仿真服务，下一次直接打开页面开始新任务。若需要关闭两项服务，运行下面的停止命令；它只管理脚本记录的进程组，退出前会核对进程启动标识，避免旧进程编号被复用后误关其他程序。详细操作另附在简短使用说明中，正文保留理解闭环所需的关键步骤。

cd /workspace/lightnav-deploy
/usr/local/miniconda3/envs/lightnav/bin/python scripts/manage.py stop

3. 效果

3.1 MicroDuck 仿真和手动控制

本次实测使用仓库打包的 MolmoSpaces ProcTHOR 验证场景 val_2，机器人为带重力、接触和十四个位置执行器的 MicroDuck。网页已经显示头部第一人称图像与第三人称跟随视图，手动前进记录到约 0.116 米平面位移，点击 STOP 后读取到线速度和角速度指令均为零，RESET 后回到接近 $(6.5,13.8)$ 米的初始位置。这个测试证明了模型文件、步态策略、物理循环、画面与网页控制链条能够协同运行，后续导航验证再检查模型输出是否真正进入这一链条。

3.2 语言导航闭环运行证据

停止行为可以与固定源码的 mujoco_demo/vln_mujoco/server.py:369 对照：收到模型的停止字段后，仿真将速度命令归零并重置 MPC。测试文件中的 terminal_prediction 保留这一响应，而 final_health 记录发送最终 STOP 后的状态；两者对应不同时间，不能因为后者清空了路点，就误以为任务期间没有预测。下面的统计来自 evidence/lamp-run-01/summary.json，运行截图则来自随后对同一指令的重复测试。

本次以 go to the lamp on the table 为指令，从复位位置运行真实检查点，记录到 79 次不同预测响应，每次最多十个路点，整段任务约 12.53 秒后由模型发出停止信号。按每次运行状态采样积分的平面路程约 2.00 米，起终点直线距离约 1.13 米；前者包含转向与接触抖动，不能把它当成无噪声的真实路径长度。终点画面显示机器人已靠近桌子和桌灯，响应同时给出目标可见与停止，说明视觉输入、模型推理、轨迹解码、MPC 跟踪和步态执行已形成可观察闭环。

指标	桌灯任务实测
场景与机器人	ProcTHOR val_2 / MicroDuck
指令	go to the lamp on the table
运行时长	12.53 秒
运行状态样本	831 条
不同预测响应	79 次，包含终止响应
预测往返延迟	平均 157.8 毫秒，中位数 156.3 毫秒，范围 112.2–220.8 毫秒
采样平面路程 / 起终点距离	2.00 米 / 1.13 米
终止	stop=true、visible=true，最终速度指令为零

这里要保留失败证据：此前执行 turn around, go to the TV 时，模型也输出了路点并自行停止，但终点 OPOS 标记落在桌灯附近，画面不能支持“成功找到电视”。因此链条运行成功与目标语义成功必须分开判断，网页自动显示的“到达目标”来自模型自己的停止判断，并非独立评测真值。两次原始状态、双视角帧和汇总分别保存在 evidence/tv-run-02 与 evidence/lamp-run-01，桌灯任务的双视角录像位于 assets/MicroDuck桌灯导航实测.mp4，可结合画面逐帧复查。

2026-10-30 自动启动修复后，再通过上述公网域名完成 HTTPS 登录、WSS 指令发送和双视角采集。桌灯任务约 11.92 秒，记录 65 次不同预测、最多十个路点，平均预测往返延迟 154.9 毫秒，采样平面路程约 1.70 米。最终模型给出 stop=true 和 visible=true，发送最终 STOP 后控制命令为零。相机请求附时间戳以避开云平台的图片缓存。

3.3 论文结果和本次测试的范围

论文报告的十项导航仿真设置涵盖指令跟随、封闭与开放词表目标导航、动态视觉跟随，这些任务依靠不同的数据划分和评价协议定义成功率。当前交付以 MicroDuck 的单场景交互为目标，没有运行完整的 Habitat 或 EVT-Bench 基准，因此本次闭环记录不构成论文成功率复现。同样，论文给出的约 $4ms/token$ 描述生成阶段的单 token 指标，实际控制台延迟还涉及图像、历史处理、推理和通信，必须用本次记录解释，不能把两个数字直接等同。

进一步看论文的消融实验，双通道指向让八项设置的平均成功率从 $54.7\%$ 提高到 $63.0\%$，差值是 8.3 个百分点；ER 初始化则把平均成功率从 $60.5\%$ 提高到 $63.0\%$，差值为 2.5 个百分点。这些结果支持视觉空间接口和预训练能力的作用，但不能保证某个低矮视角、接触条件或指令一定成功。MicroDuck 的头部高度、运动限幅与训练样本存在差异，导航轨迹和步态之间的适配仍应通过实际运动、目标可见性与停止行为逐项观察。

4. 总结

LightNav-0 将导航中的空间判断与轨迹生成统一为 VLM 的 token 输出：双通道指向分别表达可通行位置和任务目标，三级 RVQ 用三个动作 token 表示十个连续路点，视觉历史压缩则控制长时间观察的上下文开销。这套接口让语言目标、单目图像和机器人运动能够通过同一模型衔接。