简介围绕NeRF-SLAM复现过程整理的docx文档面向已具备视觉SLAM基础、希望将神经辐射场用于稠密建图的研究生与算法开发者着力解决复现链路理解、模块衔接与常见报错排查问题。压缩包内仅1个docx文件体积约11.01MB以图文笔记形式串联Droid SLAM、RAFT光流、DBA舒尔补、Instant-NGP哈希编码与概率体素NeRF等关键内容并对追踪阶段的协方差加权、稠密Bundle Adjustment的优化思路和映射阶段的深度监督机制作了展开说明。文档结合作者实际复现经历记录深度噪声、异常值、无纹理区域以及姿态不精确时模型收敛表现的相关讨论同时保留依赖环境、数据集准备、结果与引用等章节线索便于对照代码结构与实验现象梳理整体框架。已有2326人学习可作为NeRF-SLAM入门梳理、复现对照与排错参考。1. 单目 RGB 序列进去稠密深度和辐射场出来单目 RGB 序列扔进去出来的是稠密深度图和可自由漫游的辐射场——这是 nerf-slam 最直观的卖点也是很多人第一次看它重建结果时最不适应的地方传统视觉 SLAM 给的是几百个稀疏关键点它给的是每帧每个像素都有值。这份《nerf-slam 的复现文档》就是围绕这套思路整理的工程素材从 RAFT 光流、Droid-SLAM 的更新算子到 DBA 里的舒尔补再到 Instant-NGP 的哈希编码和协方差加权的深度损失最后落到一条能照抄的 clone、编译、跑数据流程。它适合已经跑通过 ORB-SLAM 一类传统系统、想验证稠密建图到底值不值得换的人也适合只想搞清 NeRF 和 SLAM 是怎么缝在一起、不打算从零推公式的人。先打个预防针它依赖 CUDA 和三个要自己编译的第三方库装环境的时间大概率比读算法的时间长。2. 跟踪链路拆解RAFT 到 Droid-SLAM 再到 DBA 的舒尔补怎么算跟踪端是这套系统里最容易“看着懂、动手废”的部分。它没有沿用传统 SLAM 的特征提取加描述子匹配而是把整帧图像的稠密光流作为观测再把这个观测和深度、位姿一起扔进一个可微的优化层。理解了这条链后面调参和排错才知道该看哪个张量。2.1 稠密光流顶掉特征匹配为什么单目 RGB 就够用传统方案里两帧之间的约束来自几百个关键点匹配每个匹配只给出一个像素坐标对。稠密方案把这个约束扩展到整张图的每个像素对 I1 上的任意像素 p都能通过光流找到它在 I2 上的对应位置。信息量差两个数量级代价是每一对像素都要算相关度显存和算力开销随之上升。这也是它能处理无纹理区域的根本原因——墙面、桌面这类区域提不出稳定角点但像素级的强度变化和几何一致性依然存在。文档里强调“输入只需要 RGB”底气就来自这里深度不是传感器给的是优化出来的所以不需要 RGB-D 硬件。要留意的是稠密不等于精确。光流在遮挡边界、反光表面、快速运动处同样会失效所以后面才必须引入协方差——让建图端知道哪些像素的深度不能信。2.2 RAFT 的相关体一个能自己验算的 4D 张量构造RAFT 的结构拆开就三块特征编码器加上下文编码器、相关层、GRU 更新算子。真正吃显存的是相关层它把两帧特征图的所有点对做内积得到一个维度为 W×H×W×H 的四维体。自己在本地跑通这一步比读十遍图更容易理解为什么它要配多尺度。import torch import torch.nn.functional as F def build_corr_volume(fmap1, fmap2, num_levels4): fmap1 / fmap2: [B, C, H, W]分别来自 I1、I2 的特征编码器输出。 返回一组多尺度相关体供 GRU 更新算子按投影坐标 p_ij 查表。 b, c, h, w fmap1.shape # 特征先做 L2 归一化内积就退化成余弦相似度数值范围稳定 f1 F.normalize(fmap1, p2, dim1) f2 F.normalize(fmap2, p2, dim1) # 全对点积 - [B, H1*W1, H2*W2]这一步的内存是 H*W*H*W*B*4 字节 corr torch.bmm(f1.flatten(2).transpose(1, 2), f2.flatten(2)) corr corr.view(b, h, w, h, w) / (c ** 0.5) # 按通道数缩放防内积随维度膨胀 volumes [corr] for _ in range(1, num_levels): # 只对 I2 一侧的空间维度做平均池化得到由细到粗的多尺度体积 pooled F.avg_pool2d(corr.flatten(0, 2), kernel_size2, stride2) corr pooled.view(b, h, w, pooled.shape[-2], pooled.shape[-1]) volumes.append(corr) return volumes逻辑说明bmm那一步把特征图展平成 [B, HW, C] 和 [B, C, HW]矩阵乘直接得到所有点对的相似度view把它还原成四维索引形式之后给定 p 在 I1 的坐标和 p_ij 在 I2 的坐标就能用双线性采样取证。参数num_levels控制金字塔层数层数多能覆盖大位移但查表时要在每层都做一次采样开销线性增长c ** 0.5这个缩放不能省通道数一大内积数值会溢出到相关性全部饱和。2.3 Droid-SLAM 改了更新算子残差落在像素上而不是位姿上RAFT 的 GRU 直接回归光流增量Droid-SLAM 把这一步改造了卷积 GRU 不再输出位姿和深度的残差而是输出投影点 p_ij 的残差 r_ij 和对应的置信权重 w_ij。这个改动看着小实际决定了整个系统能不能和传统 BA 对接。原因在于位姿和深度到像素坐标之间隔着投影和反投影是非线性的先把观测误差压到像素空间再用解析的雅可比把它映射回位姿和深度的增量就变成了标准的加权最小二乘可以直接套用舒尔补那一套成熟的求解器。这也是它能复用 GTSAM 生态的前提。实操上这一步的输出张量要重点看两个量r_ij的绝对值分布正常情况下绝大多数像素应该落在亚像素级别w_ij的直方图如果大量元素接近 0说明这一帧的匹配整体不可信多半是运动过快或者曝光变化太剧烈。2.4 DBA 的舒尔补与 Cholesky相机先解、深度回代、协方差顺手拿到稠密 BA 的 Hessian 规模是 (6N M) 量级M 是像素数直接求逆不可能。文档里点出的做法是先消路标因为路标数量远大于相机数量先对深度块做消元把问题压缩到只剩相机位姿的小矩阵上。推导写成矩阵分块就是把 H 拆成相机块 H_cc、路标块 H_pp、耦合块 H_cp先构造舒尔补 S H_cc − H_cp·H_pp⁻¹·H_pc解出位姿增量 δ_c再回代求深度增量 δ_d。S 的维度只有 6N×6NN 是滑窗内的关键帧数一般十几帧Cholesky 分解几毫秒就能做完。import torch def solve_dba(H_cc, H_cp, H_pp, g_c, g_p, damping1e-4): 稠密 BA 的一步求解。 H_cc: [N, 6, 6] 相机块 H_cp: [N, 6, M] 相机-路标耦合块 H_pp: [M] 路标块按对角近似否则存不下 Hpp_d H_pp damping # 阻尼无纹理区域 H_pp 会趋近 0 Hcp_scaled H_cp * (1.0 / Hpp_d).view(1, 1, -1) S H_cc - torch.einsum(ncm,nkm-nck, Hcp_scaled, H_cp) rhs g_c - torch.einsum(ncm,m-nc, H_cp, g_p / Hpp_d) delta_c torch.linalg.solve(S, rhs) # Cholesky 内部完成 delta_d (g_p - torch.einsum(ncm,nc-m, H_cp, delta_c)) / Hpp_d return delta_c, delta_d, S逻辑说明Hcp_scaled先把 1/H_pp 乘进耦合块的列方向后面一次einsum就等价于 H_cp·H_pp⁻¹·H_cpᵀ避免显式构造 M×M 的逆矩阵。damping是关键参数稠密场景下总有像素的 H_pp 接近零不加阻尼torch.linalg.solve会直接返回 NaN而这个 NaN 会顺着回代污染整帧深度。回代之后S 的逆矩阵对角块就是位姿的边缘协方差路标侧的边缘协方差近似为 (H_pp − H_pc·H_cc⁻¹·H_cp)⁻¹Droid 里用对角近似把它简化成一个逐像素的标量。这批标量一路传到建图端就是深度损失的权重来源。提示调试 DBA 时先把 damping 调大到 1e-2 跑几帧确认位姿增量量级正常平移在毫米到厘米级、旋转在毫弧度级再逐步调小比一上来就追求精度更容易定位问题。3. 建图端 Instant-NGP哈希编码、体渲染与协方差加权的深度损失跟踪端交出的是位姿、深度和协方差三样东西建图端要做的就是把它们变成一个连续的辐射场。这里的核心矛盾很朴素NeRF 效果好但慢SLAM 要求实时所以必须有一个能在几十秒内收敛的表示Instant-NGP 的哈希编码就是干这个的。3.1 多分辨率哈希编码把 NeRF 训练从几小时压到几分钟的那层窗户纸纯 MLP 的 NeRF 慢在位置编码高频细节要靠很宽的网络去拟合收敛慢。哈希编码换了个思路把空间切成多级分辨率的网格每个格点存一个可学习的小特征向量查表加插值就得到编码MLP 只需要很浅的几层。冲突是这个设计的代价哈希表容量固定不同格点会撞到同一个桶里。撞了不会错因为网络会学着去补偿但撞得太多细节就糊。所以表大小和场景尺度要匹配屋子级别的场景用 2^19 个桶基本够城市级肯定不够。参数含义常见取值调大的后果L多分辨率层数16细节更丰富显存线性增长T每层哈希桶数2^19冲突率下降显存是硬约束N_min最粗层分辨率16太小会导致大尺度结构学不动N_max最细层分辨率512 ~ 2048决定能恢复的最小几何尺度F每层特征维度2表达能力上升查表带宽上升实际调的时候先按显存把 T 定死再动 N_max。N_max 太小重建出来像被磨皮过N_max 太大而 T 不够冲突率飙升训练损失会抖得厉害。3.2 体渲染的离散累积每条光线采多少点、怎么分配NeRF 的输出是沿射线的积分落到实现上就是分层采样加 alpha 合成。这部分代码不复杂但采样策略直接决定训练速度很多“跑得动但收敛慢”的问题都出在这。import torch def volume_render(sigma, rgb, t_vals): sigma: [N_rays, N_samples] 密度 rgb: [N_rays, N_samples, 3] t_vals: [N_rays, N_samples] 采样点距离必须升序 dists t_vals[:, 1:] - t_vals[:, :-1] dists torch.cat([dists, dists[:, -1:]], dim-1) # 最后一段沿用上一段长度 alpha 1.0 - torch.exp(-sigma * dists) T torch.cumprod( torch.cat([torch.ones_like(alpha[:, :1]), 1.0 - alpha 1e-10], dim-1), dim-1 ) weights alpha * T[:, :-1] # 每个采样点的贡献权重 depth (weights * t_vals).sum(-1) # 期望深度就是深度监督要对的量 color (weights[..., None] * rgb).sum(-2) return color, depth, weights逻辑说明1e-10是数值保护防止透射率累乘到 0 之后对数运算出问题少了它在深度图边缘会出现整片 NaN。depth用期望而不是最大权重位置是为了让梯度更平滑代价是薄结构栏杆、树枝的深度会被前后表面平均掉这是后面深度损失要额外处理的场景。采样点数一般两段式先粗采 64 个点均匀分布再根据粗采的权重分布做重要性采样补 32 个点。只做均匀采样的话近处平面精度够、远处细节全丢只做重要性采样则容易漏掉初始没采到的区域。3.3 协方差加权的深度损失MSE 会把噪声当成真值文档里那个对比实验值得反复看有真值深度加真值位姿收敛又快又准只有真值位姿没深度慢但能收敛给了有噪声的位姿和深度六十秒内根本不收敛。关键差别不在数据量在于有没有告诉优化器“哪个像素的深度不可信”。直接对深度做 MSE 的后果是无纹理区域那些靠先验猜出来的深度被当成真值参与优化梯度的方向被系统性带偏。加权之后损失变成标准化残差的形式本质是马氏距离残差先除以该像素的标准差再平方方差大的像素自然贡献小。def cov_weighted_depth_loss(depth_pred, depth_gt, sigma_d, lam_d1.0, eps1e-6): depth_pred / depth_gt: [N_rays] sigma_d: [N_rays] 跟踪端给出的深度标准差 var sigma_d ** 2 eps w 1.0 / var w torch.clamp(w, maxtorch.quantile(w, 0.95)) # 截断长尾 return lam_d * (w * (depth_pred - depth_gt) ** 2).mean()逻辑说明lam_d是颜色损失和深度损失之间的平衡项文档里给的是 1.0这个值不要随便改改了要重新标定另一侧的权重。quantile那一行是实操中必须加的跟踪端偶尔会给出极小方差权重瞬间放大几个数量级一条射线就能把整个 batch 的损失拉飞表现出来就是损失曲线突然尖峰。还有一个容易错的地方跟踪端给的是逆深度的边缘协方差进建图之前要换算成深度协方差σ_z σ_d / d²。忘了这步换算近处像素会被过度加权重建结果近景精细、远景塌陷。3.4 参数怎么定λ_D、哈希表大小与每步光线数这三个数是复现时最先要拍定的。λ_D 照文档取 1.0哈希表大小按显存反推24G 卡可以从 2^19 起步每步光线数决定吞吐2560 条是能兼顾收敛速度和迭代频率的经验值。每步光线数不是越大越好。光线采样是随机的一个 batch 覆盖的像素太少梯度噪声大太多则单步耗时上升同样的墙钟时间里迭代次数下降。实测下来在单卡上把每步光线数和哈希表大小一起调比单独调某一个收益明显。另外要盯住的是训练时的有效像素比例。如果一帧里超过三成的像素因为协方差过大被压到接近零权重说明跟踪端这一帧本身就不稳继续训只会把错误的几何刻进哈希表。这种情况我一般直接跳过该帧等跟踪恢复正常再续。4. 环境从零搭起torch、cmake、GTSAM 与 Boost 的依赖顺序这套代码的依赖关系不是平铺的是链式的torch 的 CUDA 版本决定 ngp 能不能编cmake 版本决定 ngp 能不能配Boost 决定 GTSAM 的 Python 包装能不能出来。顺序错了就得反复回退所以这一章按依赖顺序写。4.1 Python 侧先装干净torch 和 requirements 的顺序不能反先把虚拟环境立起来再装 torch最后才装 requirements。反过来的话requirements 里某些包会顺着依赖把 CPU 版 torch 拉下来后面编译 ngp 就找不到 CUDA 符号。python -m venv .venv source .venv/bin/activate # CUDA 11.3 对应的 wheel版本号必须和本机驱动支持的 CUDA 大版本对齐 pip install torch1.12.1cu113 torchvision0.13.1cu113 \ --extra-index-url https://download.pytorch.org/whl/cu113 pip install -r requirements.txt pip install -r ./thirdparty/gtsam/python/requirements.txt装完立刻验证别等到编译阶段才发现装错python -c import torch; print(torch.__version__, torch.cuda.is_available())cuda_is_available()返回 False 的话先查驱动版本和nvcc --version两者大版本对不上就换 wheel不要试图靠改环境变量绕过去。4.2 cmake 版本是硬门槛3.22 以下直接配不过Instant-NGP 的 CMakeLists 里用了 3.22 才引入的特性低版本会报语法错误而不是提示版本不够容易误判成代码问题。先查版本再决定升不升。cmake --version # 低于 3.22 就继续往下 # 用官方预编译包比源码编译快得多 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 sudo cp -r cmake-3.22.0-rc2-linux-x86_64/bin/* /usr/local/bin/ hash -r # 清掉 shell 的命令路径缓存否则还是指向旧版本 cmake --versionhash -r这行经常被漏掉表现是明明装完了cmake --version还是显示旧版本号。如果想更干净用pip install cmake3.22.4装在虚拟环境里不污染系统路径换机器时也不用重来一遍。4.3 Instant-NGP 的编译链GLEW 只是第一个报错配置和编译分两步走先用 RelWithDebInfo 而不是 Release出了段错误还能拿到行号。cmake ./thirdparty/instant-ngp -B build_ngp -DCMAKE_BUILD_TYPERelWithDebInfo cmake --build build_ngp --config RelWithDebInfo -j$(nproc)第一次配基本都会停在Could NOT find GLEW。这是 OpenGL 扩展库ngp 的交互式查看器要用sudo apt install libglew-dev装完重跑配置。如果接着报 CUDA 架构不支持去 CMakeCache 里找CMAKE_CUDA_ARCHITECTURES把它改成你显卡实际的算力代号-j$(nproc)在内存小的机器上会 OOM改成-j4稳一点。4.4 GTSAM 与 BoostPython 包装能不能编出来取决于 b2 的参数GTSAM 的配置阶段会检查 Boost要求至少 1.65且 serialization、system、filesystem 这几个库都要在。系统源里的 Boost 常常缺组件稳妥做法是从源码编一份完整的。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 # --with-python 必须指向虚拟环境里的解释器否则 GTSAM 的 python 包装会编到系统 python 上 ./bootstrap.sh --with-python$(which python3) sudo ./b2 --buildtypecomplete install -j$(nproc) sudo ldconfig--buildtypecomplete会编全部组件耗时大概十几分钟好处是不会再因为缺某个子库返工。想本文还有配套的精品资源点击获取
简介围绕NeRF-SLAM复现过程整理的docx文档面向已具备视觉SLAM基础、希望将神经辐射场用于稠密建图的研究生与算法开发者着力解决复现链路理解、模块衔接与常见报错排查问题。压缩包内仅1个docx文件体积约11.01MB以图文笔记形式串联Droid SLAM、RAFT光流、DBA舒尔补、Instant-NGP哈希编码与概率体素NeRF等关键内容并对追踪阶段的协方差加权、稠密Bundle Adjustment的优化思路和映射阶段的深度监督机制作了展开说明。文档结合作者实际复现经历记录深度噪声、异常值、无纹理区域以及姿态不精确时模型收敛表现的相关讨论同时保留依赖环境、数据集准备、结果与引用等章节线索便于对照代码结构与实验现象梳理整体框架。已有2326人学习可作为NeRF-SLAM入门梳理、复现对照与排错参考。1. 单目 RGB 序列进去稠密深度和辐射场出来单目 RGB 序列扔进去出来的是稠密深度图和可自由漫游的辐射场——这是 nerf-slam 最直观的卖点也是很多人第一次看它重建结果时最不适应的地方传统视觉 SLAM 给的是几百个稀疏关键点它给的是每帧每个像素都有值。这份《nerf-slam 的复现文档》就是围绕这套思路整理的工程素材从 RAFT 光流、Droid-SLAM 的更新算子到 DBA 里的舒尔补再到 Instant-NGP 的哈希编码和协方差加权的深度损失最后落到一条能照抄的 clone、编译、跑数据流程。它适合已经跑通过 ORB-SLAM 一类传统系统、想验证稠密建图到底值不值得换的人也适合只想搞清 NeRF 和 SLAM 是怎么缝在一起、不打算从零推公式的人。先打个预防针它依赖 CUDA 和三个要自己编译的第三方库装环境的时间大概率比读算法的时间长。2. 跟踪链路拆解RAFT 到 Droid-SLAM 再到 DBA 的舒尔补怎么算跟踪端是这套系统里最容易“看着懂、动手废”的部分。它没有沿用传统 SLAM 的特征提取加描述子匹配而是把整帧图像的稠密光流作为观测再把这个观测和深度、位姿一起扔进一个可微的优化层。理解了这条链后面调参和排错才知道该看哪个张量。2.1 稠密光流顶掉特征匹配为什么单目 RGB 就够用传统方案里两帧之间的约束来自几百个关键点匹配每个匹配只给出一个像素坐标对。稠密方案把这个约束扩展到整张图的每个像素对 I1 上的任意像素 p都能通过光流找到它在 I2 上的对应位置。信息量差两个数量级代价是每一对像素都要算相关度显存和算力开销随之上升。这也是它能处理无纹理区域的根本原因——墙面、桌面这类区域提不出稳定角点但像素级的强度变化和几何一致性依然存在。文档里强调“输入只需要 RGB”底气就来自这里深度不是传感器给的是优化出来的所以不需要 RGB-D 硬件。要留意的是稠密不等于精确。光流在遮挡边界、反光表面、快速运动处同样会失效所以后面才必须引入协方差——让建图端知道哪些像素的深度不能信。2.2 RAFT 的相关体一个能自己验算的 4D 张量构造RAFT 的结构拆开就三块特征编码器加上下文编码器、相关层、GRU 更新算子。真正吃显存的是相关层它把两帧特征图的所有点对做内积得到一个维度为 W×H×W×H 的四维体。自己在本地跑通这一步比读十遍图更容易理解为什么它要配多尺度。import torch import torch.nn.functional as F def build_corr_volume(fmap1, fmap2, num_levels4): fmap1 / fmap2: [B, C, H, W]分别来自 I1、I2 的特征编码器输出。 返回一组多尺度相关体供 GRU 更新算子按投影坐标 p_ij 查表。 b, c, h, w fmap1.shape # 特征先做 L2 归一化内积就退化成余弦相似度数值范围稳定 f1 F.normalize(fmap1, p2, dim1) f2 F.normalize(fmap2, p2, dim1) # 全对点积 - [B, H1*W1, H2*W2]这一步的内存是 H*W*H*W*B*4 字节 corr torch.bmm(f1.flatten(2).transpose(1, 2), f2.flatten(2)) corr corr.view(b, h, w, h, w) / (c ** 0.5) # 按通道数缩放防内积随维度膨胀 volumes [corr] for _ in range(1, num_levels): # 只对 I2 一侧的空间维度做平均池化得到由细到粗的多尺度体积 pooled F.avg_pool2d(corr.flatten(0, 2), kernel_size2, stride2) corr pooled.view(b, h, w, pooled.shape[-2], pooled.shape[-1]) volumes.append(corr) return volumes逻辑说明bmm那一步把特征图展平成 [B, HW, C] 和 [B, C, HW]矩阵乘直接得到所有点对的相似度view把它还原成四维索引形式之后给定 p 在 I1 的坐标和 p_ij 在 I2 的坐标就能用双线性采样取证。参数num_levels控制金字塔层数层数多能覆盖大位移但查表时要在每层都做一次采样开销线性增长c ** 0.5这个缩放不能省通道数一大内积数值会溢出到相关性全部饱和。2.3 Droid-SLAM 改了更新算子残差落在像素上而不是位姿上RAFT 的 GRU 直接回归光流增量Droid-SLAM 把这一步改造了卷积 GRU 不再输出位姿和深度的残差而是输出投影点 p_ij 的残差 r_ij 和对应的置信权重 w_ij。这个改动看着小实际决定了整个系统能不能和传统 BA 对接。原因在于位姿和深度到像素坐标之间隔着投影和反投影是非线性的先把观测误差压到像素空间再用解析的雅可比把它映射回位姿和深度的增量就变成了标准的加权最小二乘可以直接套用舒尔补那一套成熟的求解器。这也是它能复用 GTSAM 生态的前提。实操上这一步的输出张量要重点看两个量r_ij的绝对值分布正常情况下绝大多数像素应该落在亚像素级别w_ij的直方图如果大量元素接近 0说明这一帧的匹配整体不可信多半是运动过快或者曝光变化太剧烈。2.4 DBA 的舒尔补与 Cholesky相机先解、深度回代、协方差顺手拿到稠密 BA 的 Hessian 规模是 (6N M) 量级M 是像素数直接求逆不可能。文档里点出的做法是先消路标因为路标数量远大于相机数量先对深度块做消元把问题压缩到只剩相机位姿的小矩阵上。推导写成矩阵分块就是把 H 拆成相机块 H_cc、路标块 H_pp、耦合块 H_cp先构造舒尔补 S H_cc − H_cp·H_pp⁻¹·H_pc解出位姿增量 δ_c再回代求深度增量 δ_d。S 的维度只有 6N×6NN 是滑窗内的关键帧数一般十几帧Cholesky 分解几毫秒就能做完。import torch def solve_dba(H_cc, H_cp, H_pp, g_c, g_p, damping1e-4): 稠密 BA 的一步求解。 H_cc: [N, 6, 6] 相机块 H_cp: [N, 6, M] 相机-路标耦合块 H_pp: [M] 路标块按对角近似否则存不下 Hpp_d H_pp damping # 阻尼无纹理区域 H_pp 会趋近 0 Hcp_scaled H_cp * (1.0 / Hpp_d).view(1, 1, -1) S H_cc - torch.einsum(ncm,nkm-nck, Hcp_scaled, H_cp) rhs g_c - torch.einsum(ncm,m-nc, H_cp, g_p / Hpp_d) delta_c torch.linalg.solve(S, rhs) # Cholesky 内部完成 delta_d (g_p - torch.einsum(ncm,nc-m, H_cp, delta_c)) / Hpp_d return delta_c, delta_d, S逻辑说明Hcp_scaled先把 1/H_pp 乘进耦合块的列方向后面一次einsum就等价于 H_cp·H_pp⁻¹·H_cpᵀ避免显式构造 M×M 的逆矩阵。damping是关键参数稠密场景下总有像素的 H_pp 接近零不加阻尼torch.linalg.solve会直接返回 NaN而这个 NaN 会顺着回代污染整帧深度。回代之后S 的逆矩阵对角块就是位姿的边缘协方差路标侧的边缘协方差近似为 (H_pp − H_pc·H_cc⁻¹·H_cp)⁻¹Droid 里用对角近似把它简化成一个逐像素的标量。这批标量一路传到建图端就是深度损失的权重来源。提示调试 DBA 时先把 damping 调大到 1e-2 跑几帧确认位姿增量量级正常平移在毫米到厘米级、旋转在毫弧度级再逐步调小比一上来就追求精度更容易定位问题。3. 建图端 Instant-NGP哈希编码、体渲染与协方差加权的深度损失跟踪端交出的是位姿、深度和协方差三样东西建图端要做的就是把它们变成一个连续的辐射场。这里的核心矛盾很朴素NeRF 效果好但慢SLAM 要求实时所以必须有一个能在几十秒内收敛的表示Instant-NGP 的哈希编码就是干这个的。3.1 多分辨率哈希编码把 NeRF 训练从几小时压到几分钟的那层窗户纸纯 MLP 的 NeRF 慢在位置编码高频细节要靠很宽的网络去拟合收敛慢。哈希编码换了个思路把空间切成多级分辨率的网格每个格点存一个可学习的小特征向量查表加插值就得到编码MLP 只需要很浅的几层。冲突是这个设计的代价哈希表容量固定不同格点会撞到同一个桶里。撞了不会错因为网络会学着去补偿但撞得太多细节就糊。所以表大小和场景尺度要匹配屋子级别的场景用 2^19 个桶基本够城市级肯定不够。参数含义常见取值调大的后果L多分辨率层数16细节更丰富显存线性增长T每层哈希桶数2^19冲突率下降显存是硬约束N_min最粗层分辨率16太小会导致大尺度结构学不动N_max最细层分辨率512 ~ 2048决定能恢复的最小几何尺度F每层特征维度2表达能力上升查表带宽上升实际调的时候先按显存把 T 定死再动 N_max。N_max 太小重建出来像被磨皮过N_max 太大而 T 不够冲突率飙升训练损失会抖得厉害。3.2 体渲染的离散累积每条光线采多少点、怎么分配NeRF 的输出是沿射线的积分落到实现上就是分层采样加 alpha 合成。这部分代码不复杂但采样策略直接决定训练速度很多“跑得动但收敛慢”的问题都出在这。import torch def volume_render(sigma, rgb, t_vals): sigma: [N_rays, N_samples] 密度 rgb: [N_rays, N_samples, 3] t_vals: [N_rays, N_samples] 采样点距离必须升序 dists t_vals[:, 1:] - t_vals[:, :-1] dists torch.cat([dists, dists[:, -1:]], dim-1) # 最后一段沿用上一段长度 alpha 1.0 - torch.exp(-sigma * dists) T torch.cumprod( torch.cat([torch.ones_like(alpha[:, :1]), 1.0 - alpha 1e-10], dim-1), dim-1 ) weights alpha * T[:, :-1] # 每个采样点的贡献权重 depth (weights * t_vals).sum(-1) # 期望深度就是深度监督要对的量 color (weights[..., None] * rgb).sum(-2) return color, depth, weights逻辑说明1e-10是数值保护防止透射率累乘到 0 之后对数运算出问题少了它在深度图边缘会出现整片 NaN。depth用期望而不是最大权重位置是为了让梯度更平滑代价是薄结构栏杆、树枝的深度会被前后表面平均掉这是后面深度损失要额外处理的场景。采样点数一般两段式先粗采 64 个点均匀分布再根据粗采的权重分布做重要性采样补 32 个点。只做均匀采样的话近处平面精度够、远处细节全丢只做重要性采样则容易漏掉初始没采到的区域。3.3 协方差加权的深度损失MSE 会把噪声当成真值文档里那个对比实验值得反复看有真值深度加真值位姿收敛又快又准只有真值位姿没深度慢但能收敛给了有噪声的位姿和深度六十秒内根本不收敛。关键差别不在数据量在于有没有告诉优化器“哪个像素的深度不可信”。直接对深度做 MSE 的后果是无纹理区域那些靠先验猜出来的深度被当成真值参与优化梯度的方向被系统性带偏。加权之后损失变成标准化残差的形式本质是马氏距离残差先除以该像素的标准差再平方方差大的像素自然贡献小。def cov_weighted_depth_loss(depth_pred, depth_gt, sigma_d, lam_d1.0, eps1e-6): depth_pred / depth_gt: [N_rays] sigma_d: [N_rays] 跟踪端给出的深度标准差 var sigma_d ** 2 eps w 1.0 / var w torch.clamp(w, maxtorch.quantile(w, 0.95)) # 截断长尾 return lam_d * (w * (depth_pred - depth_gt) ** 2).mean()逻辑说明lam_d是颜色损失和深度损失之间的平衡项文档里给的是 1.0这个值不要随便改改了要重新标定另一侧的权重。quantile那一行是实操中必须加的跟踪端偶尔会给出极小方差权重瞬间放大几个数量级一条射线就能把整个 batch 的损失拉飞表现出来就是损失曲线突然尖峰。还有一个容易错的地方跟踪端给的是逆深度的边缘协方差进建图之前要换算成深度协方差σ_z σ_d / d²。忘了这步换算近处像素会被过度加权重建结果近景精细、远景塌陷。3.4 参数怎么定λ_D、哈希表大小与每步光线数这三个数是复现时最先要拍定的。λ_D 照文档取 1.0哈希表大小按显存反推24G 卡可以从 2^19 起步每步光线数决定吞吐2560 条是能兼顾收敛速度和迭代频率的经验值。每步光线数不是越大越好。光线采样是随机的一个 batch 覆盖的像素太少梯度噪声大太多则单步耗时上升同样的墙钟时间里迭代次数下降。实测下来在单卡上把每步光线数和哈希表大小一起调比单独调某一个收益明显。另外要盯住的是训练时的有效像素比例。如果一帧里超过三成的像素因为协方差过大被压到接近零权重说明跟踪端这一帧本身就不稳继续训只会把错误的几何刻进哈希表。这种情况我一般直接跳过该帧等跟踪恢复正常再续。4. 环境从零搭起torch、cmake、GTSAM 与 Boost 的依赖顺序这套代码的依赖关系不是平铺的是链式的torch 的 CUDA 版本决定 ngp 能不能编cmake 版本决定 ngp 能不能配Boost 决定 GTSAM 的 Python 包装能不能出来。顺序错了就得反复回退所以这一章按依赖顺序写。4.1 Python 侧先装干净torch 和 requirements 的顺序不能反先把虚拟环境立起来再装 torch最后才装 requirements。反过来的话requirements 里某些包会顺着依赖把 CPU 版 torch 拉下来后面编译 ngp 就找不到 CUDA 符号。python -m venv .venv source .venv/bin/activate # CUDA 11.3 对应的 wheel版本号必须和本机驱动支持的 CUDA 大版本对齐 pip install torch1.12.1cu113 torchvision0.13.1cu113 \ --extra-index-url https://download.pytorch.org/whl/cu113 pip install -r requirements.txt pip install -r ./thirdparty/gtsam/python/requirements.txt装完立刻验证别等到编译阶段才发现装错python -c import torch; print(torch.__version__, torch.cuda.is_available())cuda_is_available()返回 False 的话先查驱动版本和nvcc --version两者大版本对不上就换 wheel不要试图靠改环境变量绕过去。4.2 cmake 版本是硬门槛3.22 以下直接配不过Instant-NGP 的 CMakeLists 里用了 3.22 才引入的特性低版本会报语法错误而不是提示版本不够容易误判成代码问题。先查版本再决定升不升。cmake --version # 低于 3.22 就继续往下 # 用官方预编译包比源码编译快得多 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 sudo cp -r cmake-3.22.0-rc2-linux-x86_64/bin/* /usr/local/bin/ hash -r # 清掉 shell 的命令路径缓存否则还是指向旧版本 cmake --versionhash -r这行经常被漏掉表现是明明装完了cmake --version还是显示旧版本号。如果想更干净用pip install cmake3.22.4装在虚拟环境里不污染系统路径换机器时也不用重来一遍。4.3 Instant-NGP 的编译链GLEW 只是第一个报错配置和编译分两步走先用 RelWithDebInfo 而不是 Release出了段错误还能拿到行号。cmake ./thirdparty/instant-ngp -B build_ngp -DCMAKE_BUILD_TYPERelWithDebInfo cmake --build build_ngp --config RelWithDebInfo -j$(nproc)第一次配基本都会停在Could NOT find GLEW。这是 OpenGL 扩展库ngp 的交互式查看器要用sudo apt install libglew-dev装完重跑配置。如果接着报 CUDA 架构不支持去 CMakeCache 里找CMAKE_CUDA_ARCHITECTURES把它改成你显卡实际的算力代号-j$(nproc)在内存小的机器上会 OOM改成-j4稳一点。4.4 GTSAM 与 BoostPython 包装能不能编出来取决于 b2 的参数GTSAM 的配置阶段会检查 Boost要求至少 1.65且 serialization、system、filesystem 这几个库都要在。系统源里的 Boost 常常缺组件稳妥做法是从源码编一份完整的。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 # --with-python 必须指向虚拟环境里的解释器否则 GTSAM 的 python 包装会编到系统 python 上 ./bootstrap.sh --with-python$(which python3) sudo ./b2 --buildtypecomplete install -j$(nproc) sudo ldconfig--buildtypecomplete会编全部组件耗时大概十几分钟好处是不会再因为缺某个子库返工。想本文还有配套的精品资源点击获取
