简介围绕NeRF-SLAM复现整理的docx文档面向已具备视觉SLAM与深度学习基础、希望动手实现稠密三维重建的研究生和算法工程师。压缩包内仅1个docx文件大小约11.01MB内容集中便于按主题通读已有2326人学习。文档先对比传统稀疏关键点SLAM与NeRF稠密建图的差异再按追踪与建图两条主线展开追踪部分梳理基于协方差的稠密SLAM、Instant-NGP深度监督与边缘协方差加权并延伸到RAFT光流、Droid SLAM及稠密BA层说明舒尔补与Cholesky分解如何求解相机位姿和逆深度建图部分讨论概率体素化NeRF、哈希编码加速、建图损失及深度损失设计。作者还记录了复现中遇到的问题与处理思路对复现路线、关键公式和排错线索均有交代可帮助读者理解实验配置、模块衔接与调参方向适合作为论文阅读和工程复现之间的参考材料。1. 单目视频喂进去稠密地图长出来我第一次把一段手机拍的单目视频喂进 nerf-slam 的复现流程时最反直觉的地方在于跟踪前端根本不需要深度相机。整条链路只吃连续 RGB 图像位姿和逆深度由 Droid-SLAM 这套稠密光流方案估出来稠密的三维重建结果则交给 Instant-NGP 在后台一点点长出来。它适合两类人一类是想把 NeRF 从摆拍式重建推到边走边建的算法同学另一类是手里有视频、想拿到可渲染稠密地图的工程同学。这份复现文档的价值不在论文推导而在于把 RAFT 光流、DBA 舒尔补求解、hash 编码体渲染这条长链路连同 cmake、glew、boost、gtsam 一堆编译依赖全部踩过一遍并记了下来——新手照着能跑通熟手能直接看架构取舍。2. 架构拆解一条 RGB 输入如何被两套网络分食2.1 从 Img1/Img2 到稠密地图的完整数据流整个系统的输入是连续单目图像序列这里记作 Img1、Img2以及它们之间的时间戳。数据流的起点是一对相邻帧先经过 RAFT 风格的特征编码器提取逐像素特征构建 4D correlation volume再由 Droid-SLAM 的 convGRU 迭代更新输出像素级残差和置信度这些量进入 DBA 层被映射成相机位姿修正和逆深度修正。到这里跟踪线程交出的是一串位姿 T 和一张逐像素逆深度图 D。关键在下一步这张 D 不是最终产物而是作为监督信号送给 Instant-NGP。NeRF 一侧同时接收 RGB 图像 I 和深度 D深度项由 Droid 算出的边缘协方差 ΣD 加权颜色项照常做体渲染的光度监督。两路损失一起反传更新的是哈希网格和 MLP 的神经参数 θ。原文那张架构图里蓝色是 Droid-SLAM 的贡献粉色是 Rosinol 那条概率体素路线的贡献红色是这份工作自己加的部分。颜色分得清楚其实就是在说跟踪和建图不是耦合在一起联合优化的而是跟踪算完 → 协方差传下去 → 建图带权监督的串联结构。这种松耦合的好处是每一段都能单独替换、单独调试坏处是跟踪崩了后面的建图再准也救不回来。2.2 三个上游工作的分工RAFT、Droid-SLAM、Instant-NGP把依赖拆开看这个项目其实站在三个巨人肩上每个负责一段职责边界很清楚组件负责的事输出的东西在本项目里的角色RAFT光流估计提供 correlation volume 与迭代更新范式多尺度 4D 相关体、光流增量提供前端匹配的骨架Droid-SLAM把光流更新改造成位姿/深度更新接 DBA 层位姿 T、逆深度 d、协方差 ΣD跟踪线程主体Instant-NGPhash 编码加速的 NeRF快速拟合辐射场颜色、深度、体密度建图线程主体RAFT 由三个主要组件构成特征编码器从两帧里各提一次逐像素特征上下文编码器只从 I1 提特征相关层把所有像素对做内积堆出一个 4D 的 W×H×W×H correlation volume更新算子拿当前光流估计去这组相关体里查表反复迭代细化。最后那个 4D 体的后两维会在多个尺度上做池化形成一组多尺度体积这是为了兼顾大位移和小细节。Droid-SLAM 改的就是更新这一段。RAFT 的 convGRU 直接回归光流Droid 则让更新算子作用在 frame graph 的边上输出的东西经 DBA 层映射成深度和位姿的修正量。这个改动看着小实际是把一个 2D 匹配问题抬成了 3D 几何优化问题也是整个方案能脱离深度真值工作的根本原因。Instant-NGP 那边负责的是速度。传统 NeRF 的 MLP 要查位置编码收敛慢hash 编码把空间切成多层网格每个网格顶点存可学习特征查表比过 MLP 便宜得多。原文以 L2 两层分辨率举例同一个空间点 x在粉色层和蓝色层分别查到不同的 hash 编码值把这些特征拼起来再送进一个小 MLP输出密度和颜色。2.3 与 nice-slam 的关键差别只要 RGB同样是把 NeRF 塞进 SLAMnice-slam 那条路线要求输入带深度而这里只需要 RGB。差别不在能不能省一个传感器而在监督信号的来源变了深度不再来自传感器而是来自 Droid-SLAM 的稠密估计并且这个估计自带不确定性——边缘区域方差大无纹理区域方差更大。所以整篇文章里最值得盯住的设计是协方差这个东西贯穿了始终。它在 DBA 里是 Hessian 逆的对角块到了建图侧就变成深度损失的逐像素权重。原文那张对比图说得很直白给真值位姿和真值深度收敛最快最准只给真值位姿不给深度也能收敛只是慢反过来给噪声位姿又没有深度60 秒内根本收不住而给真值深度加噪声位姿结果依然不错。这组实验其实是在论证一件事——只要按不确定性加权噪声深度也扛得住。这正是这份工作想要达到的工况。2.4 仓库结构与子模块分布工程上这是个典型的主仓库 子模块结构两个大头都在 thirdparty 下thirdparty/instant-ngp是 NeRF 那一半thirdparty/gtsam是因子图优化那一半gtsam 还要单独编出 Python wrapper 才能在训练脚本里 import。requirements 也分两份一份是主工程的一份在thirdparty/gtsam/python/requirements.txt装漏了会在 import 阶段才报错。# 目录结构示意按复现时的实际布局整理 nerf-slam/ ├── thirdparty/ │ ├── instant-ngp/ # hash 编码 NeRF需要 cmake 编译 │ └── gtsam/ # 因子图优化需开 GTSAM_BUILD_PYTHON ├── requirements.txt # 主工程 Python 依赖 └── ... # 跟踪 / 建图 / 数据接口脚本提示clone 时如果忘了--recurse-submodulesthirdparty 下会是两个空目录后面 cmake 报的错会非常迷惑先ls thirdparty确认不是空的再往下走。3. 核心实现拆解RAFT 光流、DBA 舒尔补与深度协方差3.1 correlation volume4D 相关体怎么建、怎么查RAFT 里最吃显存也最关键的一步是把两帧特征做全对内积。假设特征图是 H×W通道 C那么 I1 的每个像素和 I2 的每个像素都要算一次相似度结果就是一个 H×W×H×W 的四维体。直接算会爆显存所以工程上都会先降分辨率、限制搜索半径。import torch import torch.nn.functional as F def build_correlation_volume(fmap1, fmap2): fmap1/fmap2: [B, C, H, W]已归一化到单位长度 b, c, h, w fmap1.shape # 展平成 [B, C, H*W]做批量矩阵乘得到 [B, H*W, H*W] f1 fmap1.flatten(2) # [B, C, H*W] f2 fmap2.flatten(2) # [B, C, H*W] corr torch.bmm(f1.transpose(1, 2), f2) # [B, H*W, H*W] corr corr.view(b, h, w, h, w) # 还原成 4D 相关体 # 最后两维做多尺度池化得到一组金字塔体积 volumes [corr] for _ in range(3): corr F.avg_pool2d(corr.view(b, h*w, h, w), 2, 2).view(b, h, w, h//2, w//2) volumes.append(corr) return volumes这段代码的关键点有三个。torch.bmm那一步是把 4D 相关体压成两次矩阵乘避免 Python 层双循环view还原维度是为了后续按像素坐标索引多尺度池化是为了让更新算子在粗层抓大位移、在细层抠亚像素RAFT 原文用的就是这套金字塔。实际跑的时候我一般会先降到 1/8 分辨率算相关体再在查询时用双线性插值采回原尺度。全分辨率建一次 4D 体显存占用是平方级增长的单卡很容易直接 OOM这一点在避坑章节还会再提。3.2 Droid-SLAM 的改造convGRU 输出的是残差和置信度Droid-SLAM 在 RAFT 基础上的改动集中在更新算子的输出语义上。看那张 frame graph 的图算子作用在图的边上每条边对应一对帧 (i, j)。这里的 p 表示 frame i 上的像素点di 是它的逆深度通过相机投影和反投影p 用估计的位姿和深度映射到 frame j 上得到 pij。Cij 则是用 pij 去 correlation volume 里查表拿到的特征图里记作 Lr。convGRU 并不直接吐位姿和深度的残差它吐的是 pij 的残差 rij 和置信度 wij。这个设计的好处是把网络输出和几何量解耦了网络只负责说这个像素应该往哪挪、我有多确定剩下怎么把这个残差变成位姿修正交给后面的 DBA 用几何模型处理。# 更新算子的伪代码迭代 N 次每次用当前估计去相关体查表 for it in range(num_iterations): # 用当前位姿 T 和逆深度 d 把 p_i 投到 frame j得到 p_ij p_ij project(T_ij, p_i, d_i) # 在相关体里按 p_ij 双线性采样得到 Lr corr_feat sample_correlation(correlation_volumes, p_ij) # convGRU 输出像素残差 r_ij 与置信度 w_ij r_ij, w_ij, hidden update_operator(corr_feat, hidden, context) # 残差回代到逆深度和位姿的增量上交给 DBA 求解 d_i, T_ij apply_residual(p_ij, r_ij, d_i, T_ij)参数上迭代次数是精度和耗时的直接权衡原文没给具体值常见做法是训练阶段 812 次、推理阶段可以降到 46 次。置信度 wij 后面会参与加权低置信度的边在优化里几乎不起作用这相当于给网络一个我这条边不可信别听我的的出口。3.3 DBA 层舒尔补把 H 矩阵切成相机块和深度块Dense Bundle Adjustment Layer 是整个跟踪链路里最传统 SLAM的一块也是最容易看晕的一块。先把符号对齐c 和 p 分别表示 BA 里的相机和路标点p 的数量远远大于 c所以求解正规方程 H·Δ b 时不会直接求逆而是先用舒尔补把路标点消掉。设待求量是相机位姿增量 Δξ 和路标点逆深度增量 ΔdH 按这个顺序分块import torch def dba_solve(H_cc, H_cd, H_dd, b_c, b_d): 稠密 BA 的舒尔补求解 H_cc: 相机-相机块, 尺寸 6N x 6N H_cd: 相机-深度块, 尺寸 6N x M H_dd: 深度-深度块, 对角块, M x M b_c / b_d: 对应右端项 # 第一步H_dd 是对角块求逆极便宜先算 H_dd^{-1} * b_d inv_dd_bd b_d / H_dd_diag # 逐元素除M 维 # 第二步舒尔补 S H_cc - H_cd H_dd^{-1} H_cd^T S H_cc - H_cd (H_cd.T / H_dd_diag.unsqueeze(0)) # 第三步解 S * Δξ b_c - H_cd H_dd^{-1} b_d rhs b_c - H_cd inv_dd_bd delta_xi torch.linalg.solve(S, rhs) # 内部走 Cholesky: S L L^T # 第四步回代解出逆深度增量 delta_d (b_d - H_cd.T delta_xi) / H_dd_diag return delta_xi, delta_d逐段说逻辑。第一步之所以能逐元素除是因为 H_dd 本身是对角的——每个像素的逆深度只和自己耦合不跨像素这个近似在稠密 SLAM 里几乎是标配做法换来了极大的稀疏性。第二步构造舒尔补 S本质是把 M 维的深度未知量边缘化掉得到一个只有 6N 维的小系统N 通常是个位数到十几解起来毫无压力。第三步的torch.linalg.solve内部会走 Cholesky 分解也就是原文里写的 H L·Lᵀ这一步既解了方程又顺手拿到了矩阵分解。真正要留意的是第四步之后那件事边际协方差。ΣT 和 Σd 分别是相机位姿和逆深度的边际协方差它们可以从 Cholesky 因子里回代得到——具体就是用 L 做两次三角回代取对应块的对角线。Σd 就是后面建图侧深度损失的逐像素权重这条线把跟踪和建图串起来了不是随便加的一个权重项。还有一个实现细节值得单独讲Cholesky 分解只对对称正定矩阵成立S 在数值上必须是正定的。如果某一帧的观测太少、或者协方差被噪点污染S 可能退化成半正定torch.linalg.solve就会抛错或者给出离谱的解。常见做法是给对角线加一个极小的阻尼项 λI这个 λ 一般取 1e-6 到 1e-4 之间我一般从 1e-5 起调。3.4 深度协方差怎么进损失ΣD 的加权方式跟踪线程算完协方差 ΣD 会跟着深度图 D 一起送到建图侧。原文的深度损失写作对姿态 T 和神经参数 θ 的联合最小化超参 λD 用来平衡深度监督和颜色监督作者取的是 1.0。# 建图侧的深度损失用协方差 ΣD 加权压掉噪声像素的影响 depth_pred rendered_depth # NeRF 体渲染出来的深度 depth_gt tracked_depth # Droid-SLAM 估计的深度 sigma_d depth_covariance # 来自 Cholesky 回代的逐像素方差 # 方差越大权重越小加 eps 防止除零 weight 1.0 / (sigma_d 1e-6) depth_loss (weight * (depth_pred - depth_gt).abs()).mean() total_loss lambda_d * depth_loss color_loss # lambda_d 1.0这里的逻辑就一句话不确定的像素少听它的。无纹理区域、物体边缘、遮挡边界这些地方Droid 估出来的深度本身就不可靠硬拿它当监督只会把辐射场带偏。用 1/σ 加权之后可靠像素主导梯度不可靠像素基本被压成噪声。从原文的消融也能反推这个设计的必要性给真值姿态和深度是最理想情况收敛快且准只给真值姿态、没有深度靠 RGB 一样能收敛只是慢——这就是经典 NeRF 的 pose-image 输入而给噪声姿态又没深度60 秒内压根不收敛。整套工作的目标工况是噪声姿态 噪声深度靠的就是这个加权。注意λD 设成 1.0 是原文给的经验值但如果换到自己采的数据上深度噪声明显更大这个值往下调到 0.30.5 通常更稳反过来如果你的深度来自比较准的传感器可以往上抬到 2.0 左右观察收敛速度。4. 环境搭建从 cmake 3.22 到 gtsam Python wrapper4.1 依赖基线虚拟环境、torch 与两套 requirements这一套依赖对版本很挑尤其是 torch 和 CUDA 的配对。复现文档里用的组合是 CUDA 11.3 配 torch 1.12.1装的时候要带cu113后缀不然 pip 会给你拉一个 CPU 版本后面编译 instant-ngp 时链接一塌糊涂。# 带子模块克隆别漏 --recurse-submodules git clone repo --recurse-submodules cd nerf-slam git submodule update --init --recursive # 建虚拟环境原文强调从这一步开始都待在 venv 里 python -m venv venv source venv/bin/activate # CUDA 11.3 对应版本的 torch pip install torch1.12.1cu113 torchvision0.13.1cu113 \ --extra-index-url https://download.pytorch.org/whl/cu113 # 两份 requirements 都要装gtsam 那份容易漏 pip install -r requirements.txt pip install -r ./thirdparty/gtsam/python/requirements.txt命令本身没什么技术含量但顺序有讲究。torch 必须先装且装对版本因为后面编译 gtsam 的 Python wrapper 时会去链接当前环境的 Python 和 numpy 头文件如果你中途换过环境或者装了两份 numpywrapper 编出来 import 就会失败。我一般会在pip install之前先python -c import torch; print(torch.version.cuda)确认一遍。4.2 编译 instant-ngpcmake 版本、GLEW 与一条构建命令instant-ngp 这一半要求 cmake 大于 3.22这是硬门槛。Ubuntu 自带的 cmake 往往是 3.16 上下直接 cmake 过去会报CMake 版本过低或者某些语法不认识。升级方式有源码编译和直接下二进制的预编译包两条路复现文档里走的是源码/预编译包混合的一条路径大致就是下载、解压、sudo make install三步。# 先看当前版本 cmake --version # 下载 3.22 预编译包并安装需要 cmake3.22 才能配 instant-ngp wget https://cmake.org/files/v3.22/cmake-3.22.0-rc2-linux-x86_64.tar.gz --no-check-certificate tar -zxvf cmake-3.22.0-rc2-linux-x86_64.tar.gz cd cmake-3.22.0-rc2-linux-x86_64/ sudo cp -r bin/* /usr/local/bin/ sudo cp -r share/* /usr/local/share/ # 装完一定要刷 hash否则 shell 还在用旧路径 hash -r cmake --version # 配置并编译 ngp cd nerf-slam cmake ./thirdparty/instant-ngp -B build_ngp cmake --build build_ngp --config RelWithDebInfo -j第一次 cmake 大概率会停在 GLEW 上Could NOT find GLEW (missing: GLEW_INCLUDE_DIRS GLEW_LIBRARIES)。这个不是 cmake 的问题是系统缺 OpenGL 扩展加载库sudo apt install libglew-dev装完重新 cmake 就行。类似的还会缺 GLFW、X11 相关开发包报错信息里写什么就装什么这一步没什么玄学。--config RelWithDebInfo这个参数值得说一下它同时开优化和调试符号是 instant-ngp 官方推荐的构建类型。用 Debug 会慢到无法接受用纯 Release 崩溃时给的栈没法看。-j后面跟核数机器内存不够的话并发太高会在链接阶段被 OOM killer 干掉8G 内存的机器建议-j4。4.3 编译 gtsam 与 Boost 1.73源码安装与路径问题gtsam 是因子图优化库本项目要用它的 Python wrapper所以配置时必须带-DGTSAM_BUILD_PYTHON1。cmake ./thirdparty/gtsam -DGTSAM_BUILD_PYTHON1 -B build_gtsam这一步最常见的失败是 BoostCould NOT find Boost (missing: Boost_INCLUDE_DIR serialization system filesystem thread program_options date_time timer chrono regex) (Required is at least version 1.65)。系统里要么没装 Boost要么版本低于 1.65要么装了但 cmake 找不到头文件路径。稳妥的做法是源码装一个 1.73。wget https://boostorg.jfrog.io/artifactory/main/release/1.73.0/source/boost_1_73_0.tar.bz2 --no-check-certificate tar xvf boost_1_73_0.tar.bz2 cd boost_1_73_0 ./bootstrap.sh sudo ./b2 --buildtypecomplete install sudo ldconfig # 刷新动态库缓存否则运行时找不到 libboost_*--buildtypecomplete是全部编译安装图省事就这么干代价是编译时间长。Boost 默认装到/usr/local/lib如果系统里已经有一份 apt 装的旧版 Boost 在/usr/lib链接时可能优先命中旧的这时候要靠ldconfig的顺序或者显式指定BOOST_ROOT来兜底。多 Python 版本共存时./bootstrap.sh --with-pythonpython3.8这种写法能指定绑定的解释器不指定就用系统默认。Boost 装好后回到 gtsam 的 cmake 命令重跑一遍配置通过再cmake --build build_gtsam -j。编出来的 Python 模块通常落在build_gtsam/python/下需要把这一层加进PYTHONPATH才能import gtsam。这点原文档里没细说但漏了这一步会在跑训练脚本时直接 ImportError很难往编译问题上联想。4.4 数据组织与第一次启动数据这块跟踪线程要的是连续单目图像序列目录结构按帧号顺排即可位姿真值只在评估阶段用得到。启动前建议先确认三件事build_ngp下编出了可执行文件、python -c import gtsam不报错、显存至少有 8G 空闲。# 启动前自检三连 ls build_ngp/ | head python -c import gtsam; print(gtsam.__file__) nvidia-smi --query-gpumemory.free --formatcsv # 典型启动方式指定数据目录与输出目录 python run.py --data_root ./data/scene_01 --out_dir ./logs/scene_01首次跑建议只用一小段序列比如 100200 帧先把跟踪位姿和深度图存下来看趋势对不对再放到全长序列上。整条链路第一次跑通的时间成本主要花在编译上运行本身反而快。5. 避坑与排查复现路上最容易翻车的五件事5.1 现象cmake 配置 instant-ngp 直接失败报语法不支持原因基本只有一个系统 cmake 版本低于 3.22而 instant-ngp 的 CMakeLists 用了新版本才有的语法特性。这类报错通常不会明说版本低而是给一行莫名其妙的 parser error误导性极强。解决分两步。先cmake --version确认版本低于 3.22 就按第 4.2 节装一个新版装完必须hash -r否则 shell 缓存里还是旧的可执行文件路径cmake --version显示的还是老版本。多版本共存时可以用which cmake看实际命中的是哪一个必要时在 PATH 里把/usr/local/bin提到前面。5.2 现象Could NOT find GLEW或者链接阶段报一堆 GL 符号未定义原因是系统没装 OpenGL 扩展加载库的开发包或者装了但只有运行时库没有头文件。cmake 找 GLEW 依赖GLEW_INCLUDE_DIRS和GLEW_LIBRARIES两个变量缺任何一个都会走到这个分支。解决是sudo apt install libglew-dev装完重新 cmake。如果仍报错用dpkg -L libglew-dev看头文件确实落到/usr/include/GL/下没有落到了别的地方就得手动传-DGLEW_INCLUDE_DIRS...。同一类问题还会以 GLFW、X11、OpenGL 的面目出现处理方式一致。5.3 现象Could NOT find Boost缺一串 serialization/system/filesystem 组件原因有三种可能得逐个排。一是根本没装 Boost二是装了但版本低于 1.65三是装了新版但 cmake 优先找到了系统旧版的 CMake 配置文件读出来的组件列表对不上。解决是源码装 1.73 并sudo ldconfig。装完如果还报就在 cmake 命令里显式加-DBOOST_ROOT/usr/local -DBoost_NO_SYSTEM_PATHSON把搜索路径锁死到新装的那一份。这一条我踩过两次第二次是因为 apt 装过 libboost-all-dev/usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0这个目录一直抢在前面最后是把这个旧配置目录临时改名才干净解决。5.4 现象子模块目录是空的cmake 报找不到 thirdparty/instant-ngp/CMakeLists.txt原因是 clone 时没带--recurse-submodulesgit 只拉了主仓库两个子模块目录是空壳。这个错误信息很直白但新手容易慌以为是仓库结构本身有问题。解决是git submodule update --init --recursive补拉。已经拉过一半的情况加--recursive也能力挽狂澜。判断标准很简单ls thirdparty/instant-ngp和ls thirdparty/gtsam都应该有内容空的就说明没拉全。5.5 现象gtsam 编译成功但 import 失败训练脚本一起就 ImportError原因大概率是 Python wrapper 编出来了但不在sys.path上或者编译时链接的 Python 解释器和你当前 venv 里的不是同一个。后者更隐蔽编 wrapper 时如果 venv 没激活它会去链系统 Python 的头文件编出来在 venv 里 import 就会报 ABI 不兼容。解决是先echo $VIRTUAL_ENV确认在 venv 里再find build_gtsam -name gtsam*.so找到编出来的模块把所在目录加进PYTHONPATH后重试。如果是 ABI 问题只能回退到激活 venv 后重新 cmake 重编这一条路没有捷径。提示这五条里第 5.1 和 5.3 是最耗时的两个建议在动手前先把 cmake 版本和 Boost 版本各查一遍比事后 debug 省几个小时。6. 二次开发改哪几个点、怎么验证改动有效跑通之后想往前推一步改造点其实很集中按投入产出比排一下大概是这样改造目标动的位置改动量验证方式换自己的数据集数据加载与位姿初始化小前 50 帧位姿轨迹是否连续、无跳变调深度监督权重λD 与协方差加权公式极小固定迭代次数看 PSNR 与深度 L1换渲染后端Instant-NGP 的 hash 层配置中同等训练时长下的收敛曲线接入外部位姿源替换 Droid-SLAM 输出中大与真值轨迹做 ATE 对比导出网格从体密度场做 marching cubes中可视化检查孔洞与噪点最省事也最见效的是调 λD。具体做法是把 λD 做成命令行参数在 0.3、1.0、2.0 三档各跑一次短序列横轴训练迭代次数、纵轴深度 L1 和渲染 PSNR画两条曲线。如果深度项权重压得太低PSNR 会涨但几何会飘表现为重建出来的墙面有波浪权重太高收敛会明显变慢因为噪声像素在拖后腿。# 把 λD 参数化跑对比实验 parser.add_argument(--lambda_d, typefloat, default1.0, help深度监督权重噪声大时往下调深度准时往上抬) # 训练循环里按迭代数做退火前期重几何后期重外观 lam args.lambda_d * max(0.3, 1.0 - it / total_iters) loss lam * depth_loss color_loss上面这段退火是我自己加的原文里 λD 是常数。加它的动机很简单训练前期位姿和深度都还没收敛几何约束能帮着把结构先立起来到后期辐射场已经成形深度项的噪声反而会干扰颜色细节逐步降权更稳。这套写法不是官方给的属于工程上的经验补丁跑之前建议先做 A/B 对比别直接上全长序列。另一个值得动的地方是验证方法本身。我这里踩过最大的一个坑是只看渲染图好不好看不看轨迹精度。渲染图有个特性——它特别能骗人辐射场可以把错误的几何渲染得很像样但你把相机轨迹拉出来和真值一对比ATE 能差出几十厘米。从那以后我每次改完代码都强制走一遍轨迹 ATE 深度 L1 渲染 PSNR三件套三个数一起看才敢说改动有效只要有一项变差就回滚。如果要往工程化方向走建议把跟踪和建图切成两个进程用文件或者共享内存传位姿和深度图。这样跟踪崩了不用重建图建图调参也不用重跑前端调试效率会高很多。代价是多一层序列化和同步逻辑帧率低的时候要考虑丢帧策略。这个改动不算小但如果目标是长期迭代早做比晚做好。希望帮到你。本文还有配套的精品资源点击获取
