顶级三维成像系统 DIY 踩坑记（一）
做三维重建的一年多里，女儿总是会挑战我：这些东西 Google 都做了，你做了有什么用？
是的，Google 现在推出的三维沉浸模式已经覆盖了许多城市，但正如 Cesium 的演示项目一样：作为一项工具，挺不错，但是作为二维照片的升维选项，不可用。
我做三维重建的目标很明确：生成最高质量的结果，技术上和艺术上都可以比肩我的照片的那种。所以，整整一年多时间里，我都在不断的寻找算法，优化流程，也在寻找合适的硬件。
去年众筹，半个月前刚拿到的 Revopoint 的 Miraco 非常好：类似于 Makina670 折叠相机的大小，直接跟相机一样拍摄，机器内建模，速度快，质量高。
但是，缺点也非常明显：拍摄距离只能在一米之内，同时，不适应户外光照环境，所以，是一个高精度的工具，能进入我的工作流，但是对于我更想做的建筑题材，并不合适。
户外状态下，有不少建图的方案，但是效果也就是家用扫地机器人扫描一下全屋的水平。究其原因：1. 镜头质量太差，虽然现在许多产品选用多个镜头，包括 RGB-D 即带深感信息的镜头，红外镜头等，甚至有些还配备了激光雷达，但是基于综合成本的考量，分辨率更多只是做到 640X480；2. 算力受限，图像处理特别是三维重建，过于消耗算力和时间，几百块钱成本的边缘芯片，根本支撑不了哪怕 1080P 的高清。所以，为什么苹果的 Vision Pro 要定一个天价，根本原因就是在这么一个一体化的计算设备里，即使达到一般人觉得能接受的效果，成像组件和算力芯片也都是天价了。这还是建立在苹果的 Apple Silicon 芯片是目前地表最强端侧芯片的基础上。
但即使如此，成像质量也不会超过我的 86 张 2400w 像素照片用 RealityCapture 在英伟达 4090 卡上随便跑一下的结果。
而这只是开始。
往前走，是一系列的采集流程，往后走，是一系列模型和后期调整。
目前看，往前走可以优化的空间与潜力大很多，需要的工作也更多。因为决定最终质量的其实就在采集端：图像本身质量、图像的数量、图像与图像间的信息重合度。
要说完全满足这些要求的当然也有，比如我的合作品牌 Phase One。专门优化的 1.5 亿像素数码后背，专门优化的高清数字镜头，全局控制模块，导航信息模块，IMU 模块。这些，其实都还是有个价格的，真正的门槛是：需要上飞机，不是无人机那种；要有一个大团队。
即使我是 Phase One 的大使，这样的系统也不是我现在能够驾驭或者可以去驾驭的。但是，这种全球唯一的方案，结合现在越来越完善的机器人开发生态，还是给了我很多启示。我可以做一个小型地面版本的系统，控制体积和重量，大幅提升前期拍摄和数据采集效率，结合越来越方便的云端算力与模型矩阵，可以实现顶级画质。
但是，这绝对是一个耗时巨大，踩坑无数的过程。就以外拍系统而言，大概就需要一个至少是富士 GFX 中画幅级别的相机（Phase One 的后背当然更好，但是系统重量、采集效率上确实不如富士中画幅合适）。
一个英伟达 Jetson Orin 开发套件版本，256T 算力，64GB 一体化内存，支持 CUDA，CuDNN，12V 电源，35W 功耗，可以 Type-C 供电。一个小屏幕，最好能够触摸。
一套激光雷达：比如，宇树科技的 L1。
支架，等等，如果再完善，还需要配上 IMU，支持 GNSS 与北斗的 RTK，甚至，深感相机阵列。
仅仅硬件，其实都是很大的坑了，还不包括正在准备的无人小车……
本来我以为这套系统本质上是硬件选择和搭配问题，毕竟，大模型已经开启了低代码甚至无代码时代。
但是，当我在 2024 年初真的开始有时间进入动手尝试环节时，发现自己，还是太天真了……
所以，前面的都是简单描述，下面的才是真正扣题的内容：此刻，我依然陷在代码的深坑里看不到出口，只是经过了一个礼拜的折磨，总算还是似乎向上迈出了一两步的样子。所以，才有了这篇踩坑记（一）。
设想上，这套系统应该有以下功能：
- 满足绝大多数外拍环境，方便爬楼、移动；
- 一边拍摄，一边可以实时看到初步的三维成像效果，便于现场调整拍摄；
- 相机拍摄的照片能够自动完成与激光雷达、IMU，甚至高精度导航信息及深感相机数据的对齐与融合；
- 有一套界面方便进行全局控制，快速建模，实时预览。
所以，这就是为什么需要 Orin，需要屏幕，需要激光雷达，还需要可靠的供电系统，等等等等。
第一步，需要在 Orin 上安装一系列的工具：控制相机的 gphoto2，实时建图的 orb_slam，相机对齐的 colmap，实时 nerf 算法……
让这些可以正常工作，便成为了我过去一周的噩梦。
过程太过技术化，我只简述过程，即是记录，以备后续查找，同时，in case 有同样“疯狂”的人，至少希望我的简单记录，可以少踩点坑。
- 架构的坑：我用的很多代码库，基本都是面向 X86 或者 X86_64 架构的，而 Orin 是 ARM (aarch64) 架构的，所以，几乎所有的代码库都需要重新编译。很惭愧，我已经很多年没碰 C++ 了，现在的 makefile 真的越写越花哨了。
- 依赖库的坑：很多代码库底层调用其他代码库，这些也都需要重新编译，但是这些底层代码最新的更新日期也就是 21 年，有些甚至更早。如今主流的 gcc, g++ 已经到版本 14，而这些底层代码还活在版本 11 的时代。真不是一个简单的指定编译器版本的问题。
- 系统版本的坑：我花费了一个晚上，无数次重试，终于把 Jetson Orin 的开发组件 Jetpack 升级到了 6 的开发者预览版，对应 Ubuntu 版本号 22.04。结果就是，我不得不在别的设备上部署低 Ubuntu 版本的模拟 aarch64 架构的交叉编译环境。
- CUDA 的坑：CUDA，一个活了超过 15 年，已经更新到了 12.2 版本的英伟达生态圈成立的核心基础，在我这些年的部署里，我并不记得有哪一次是很顺利的。更何况，Orin 支持 CUDA 是一大优势，但是 SoC 的 CUDA 和独立 GPU 的 CUDA 并不是一个东西，至少对于很多底层三方代码库看来，他们很不一样。此处不得不表扬一下苹果，虽然他们又造了一个轮子叫做 MLX，但是自从苹果抛弃 Intel 后，对开发者而言，只要苹果硬件能够支持的，安装体验就没有不好的。当然，有很多，硬件目前还是不支持的。
- 驱动与权限的坑：几乎所有的专业相机都没有提供 Linux 版本的软件，所以需要安装 gphoto2（这是命令行工具，真正的底层支持是 libgphoto2 库），同样的问题，全部需要重新编译，基于 aarch64 架构，写得不清不楚的说明文档，重新生成的库连接，相机支持列表生成，最想不到的是，USB 接口的权限。
- 显示与 X Forwarding 的坑：OpenGL 的支持，Qt 的安装，X Forwarding，特别是 X Forwarding，以我 20 年的 Linux 经验，居然在这上面折腾了很久。因为 Mac 系统对 OpenGL 不再支持，所以无法把 Qt 的窗口抛回 macOS；由于 A100 和 H100 都不具备图形卡功能，所以也不支持 OpenGL。最后，还是回到 Windows 笔记本，进入 WSL 子系统，搞定了这些。
- 代码兼容性的坑：有些代码需要用到 Boost 库，可是，Boost 在前几年做了一次架构调整，所以，我为上百个 error 改了代码，居然，幸运的是，最终通过了。
当我最终看到上面的窗口出现在电脑屏幕上时，总算是迈出了第一步的感觉。当可以处理图片数据流时，我知道，拼图已经完整了。虽然，后面依然有极大量的工作。
PS：其实在这个过程中无论是用的硬件类型，还是代码库，都是现在主流自动驾驶和机器人算法需要用到的。在越来越梦幻，越来越未来感的外表之下，是那么多其实已经要开始过时的底层代码。
昨天，我在朋友圈发了一句话：搞钱的，没空重写底层，不搞钱的，没动力重写底层。
我也没动力重写，也许我会去寻找跳过这些底层的方法。