基于AlgoT1设备改进多源融合定位算法(GNSS+INS+VISION)

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.结论

  1. 基于开源代码改进后的代码,能够获取比较稳定的GNSS+INS+VISION结果,根源是改掉了若干非常严重的逻辑漏洞和错误,需加大测试量,来完善其它可能的bug;
  2. 从处理urban38的数据来看,局部存在毛刺,而处理AlgoT1的数据情况就要好一些,对不同的相机,算法部分存在很多点不能通用的地方,或者需要加强的地方,需要针对性改进。
相关推荐
YHPsophie2 天前
AT6558F高性能BDS/GNSS多模卫星导航接收机SOC单芯片
gps·gnss·soc芯片·bds·卫星导航接收机·at6558f
橘色的喵6 天前
GNSS和PTP时间同步的基础原理介绍
gnss·phy·ptp·时间同步·gptp
Mr.Peng~NtripShare12 天前
NtripShare Cloud平台之CORS服务之基准站RTCM坐标编辑
gnss·北斗·ntripshare·gnss接收机·rtcm
做完作业了1 个月前
RTKLIB学习记录【postpos、execses_b、execses_r】
gnss·rtklib·rtklib源码解析
小 y 同 学2 个月前
Ubuntu22.04安装GNSS数据处理软件GAMIT/GLOBK
linux·gnss·测绘·gamit
记得往前走2 个月前
北斗卫星系统信号介绍
gnss
山东仁科2 个月前
自然灾害预警系统的重要性
gnss·自然灾害·预警系统
山东仁科2 个月前
桥梁在线监测解决方案:科技赋能,守护桥梁安全
gnss·在线监测·桥梁
黄小鹿2 个月前
【GNSS射频前端】MA2769初识
fpga·gnss·北斗
山东仁科2 个月前
水库大坝预警解决方案:守护生命线的科技防线
gnss·水库大坝·水库大坝预警