AlgoT1是融合了GNSS+IMU+VISION的数据平台，并且在开源代码上进行了改进，用该设备实测了一组数据，得到的效果还行，对做多源融合算法研究是个不错的选择。
0.设备图
这款设备是上海代数律动技术有限公司新出的机器(http://www.algotechrobot.com/)，有单目版和双目版两个版本，这次测试用的单目版，来张靓图：
1.跑AlgoT1数据（GNSS+INS+VISION）
基于开源的改进的算法，整体轨迹图，连续平滑：
视觉的跟踪：
2.改进的GNSS+INS+VISION版本和GNSS+INS对比
该改进版本和GNSS+INS对比，从轨迹连续度上没有非常明显的差距，有特性的不一样，需要继续查找原因，在轨迹重合度上在，在地库完全无GNSS信号时带视觉的要好，完全无信号情况下，如果不加高程约束，纯INS高程方向一般都会飘（如果没有NHC约束，平面方向也会飘），但是在视觉参与后，高程无约束下仍然稳定：
整体轨迹重合度，GNSS+INS+VISION和GNSS+INS整体重合度较好，说明带视觉结果整体正常：
带视觉的在地库表现：
GNSS+INS在地库表现：
3.跑开源数据urban38
为了验证针对AlgoT1数据改进的程序逻辑上是正确的，来跑开源数据urban38，结果至少正常才能说明改进的正确性。
原生代码跑该数据（原生代码跑开源数据urban38，结果存在随机性，时好时坏，根源源于原生代码有bug），跑的差的一次：
用针对AlgoT1数据改进的版本跑：
从跑的结果来看，整体上改进后的结果轨迹重合度更好，但是存在在细节地方有突起的地方，说明改进的内容在宏观上是对的，细节处理不足。
两个结果叠加结果对比：
用原生代码跑urban-38正常状态下，不触发逻辑错误的结果，结果是很好的，整体重合度和改进版本差不多，但有些细节部分其实更好：
4.结论
- 基于开源代码改进后的代码，能够获取比较稳定的GNSS+INS+VISION结果，根源是改掉了若干非常严重的逻辑漏洞和错误，需加大测试量，来完善其它可能的bug；
- 从处理urban38的数据来看，局部存在毛刺，而处理AlgoT1的数据情况就要好一些，对不同的相机，算法部分存在很多点不能通用的地方，或者需要加强的地方，需要针对性改进。