主流VIO/VSLAM系统改造与工程化落地

今天主要写针对主流VIO和VSLAM如VINS-MONO和DSO的工程改造思路

肯定是有相当价值的，总体写得比较简单，需要具备软件/硬件/算法等各方面综合能力才能掌握主要路径，具体实现方面以后由其他同事来针对每一个单一闭环来更新。

主流VIO系统核心问题如下：

1. ZUPT零速修正与各种特殊场景失效的问题：

这个在前文已经详细描述过6-7类常见问题，目前也已经在工程上完整的解决了，除了长时间的问题重复(如持续长时间的无纹理)或超长回环，其他问题均得到了很好的解决。在此提醒大家，使用的相机必须是室内全局快门+硬件MCU同步Td(最终Td控制到近乎于0)，室外如果使用卷帘相机必须精确掌握曝光时间，才能够比较完美的闭环相关工程问题实现商用。我们在Real sense/Kinect V2/小觅等设备上均尝试了一系列工程，即使完成了所有工程部分，用i7-12代这类强算力平台跑结果均不理想(Kinect V2略好)。最终还是被迫自研了相机组件去彻底闭环了硬件问题。

2.主系统在工程侧沉重开销的设计

VINS-MONO和DSO都是很棒的系统，但是因为分别都属于实验室，即使后续扩展的VINS-Fusion和VI-DSO等，除了问题1外，仍存在工程侧沉重开销的问题。这里有2块必须解决掉的部分

(1)前端视频流显示与指引部分，作用是给人机界面清晰的视频指引，并准确让用户感知到初始化是否成功以及点跟踪的情况。这个部分是大家很少去注意的。如实验室的工程师们使用的Pangolin和RVIZ，VINS和DSO等都是直接拖出裸数据再用OPENCV软件进行叠点显示，这样会造成严重的问题，RAW DATA处理很吃开销，直接用CPU调库叠点开销更重。这类设计会导致改造后的主系统几乎无法在嵌入式系统上运行。即使能运行，这类视觉数据传输到用户端也有巨大的延迟。

 

解决手段：利用强力的视觉SOC的编解码引擎进行编码Encoding处理，并使用其OSD等硬件叠图算子去处理和解决。这样的话无论在用户PC端还是嵌入式系统端均解决了视频流长延时和重开销的问题。这块虽然是我的专业，但如何做就不展开了，展开又是5万字。但本质这个事是个大成熟的机器视觉主流领域，一些基础SOC如海思3519A等就可以轻松实现，方案也比较多。需要具备较强的PCBA与SOC/嵌入式开发能力。

(2)3D点云与姿态展示部分，这个部分是很难处理的，实际改造后的VIO/VSLAM系统输出的核心数据就2种：点的逆深度信息(或齐次坐标等空间3维坐标描述形式)和相机位姿。对于大部分大系统来说这2块信息封装好SDK做好数据结构体即可。但问题来了，用户端或迟或早还是一定要做展示和人机交互的，这里就必须进行3D点云的处理。VINS和DSO在这块使用的RVIZ和Pangolin等是可以扩展的，但是不建议使用。

 

解决手段：如果要在嵌入式系统上做，用NV方案就不讨论了，很简单。如果用Mali等GPU方案，因为生态很差，需要精通Opencl的使用。这个也没法教，可以先忽略不计。

比较好的处理手段是在PC端上进行扩展自行开发(具备NV和Intel的GPU生态)，首先做好点与位姿数据的结构体处理，再封装好SDK，这里方法1是建议使用PCL点云库结合QT进行开发(C++归一环境)，方法2是在浏览器端开发，展开又是5万字的东西不写了。大家看看自己技能偏向哪方面就在那个方面做即可，并不难，一开始实现基础的旋转/平移/缩放即可。

这2项工作都是沉重和工作量较大的，尤其是在不具备相关研发能力的情况下；但是同样这2块工作也是必须要完成的，否则你的VIO/VSLAM系统也就是个普通的实验室研究罢了，不具备在工业界和其他用户侧落地的基础能力！有95%甚至以上的用户，是不会腾挪出额外的主控资源，去给这些无谓的工作提供算力开销。

PS: 核心资源从来都是留给最核心的系统的，在VIO或其他的多传感器融合融态中，最核心的系统仅指前端和后端，连回环都勉强只能算一半！