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的数据情况就要好一些,对不同的相机,算法部分存在很多点不能通用的地方,或者需要加强的地方,需要针对性改进。