Open lddnb opened 5 months ago
hi 感谢关注! 我已经把 https://github.com/sheng00125/LIV_handhold 中的同步方案更新,之前有一些bug,您可以重新烧一下stm32的固件。另外您之前采集的bag可以发给我,我测试一下看看有什么问题。
感谢回复! STM32的GPRMC信号发送部分我之前自己修改过,和您更新的内容差不多 图示场景bag的Google Drive链接我已发送到了您的邮箱zhengcr@connect.hku.hk,并附上了当时测试时使用的配置文件、标定文件和launch启动文件,如果还需要什么数据,或发现什么问题,请联系我 祝好
我测试了下,外参貌似在pitch角上有点问题,可以稍微注意下。同步也没什么问题,但应该是错开了一帧,相机的时间戳应该+0.1s,可以在callback函数里面实现。以下是我测试的截图和raw point的pcd文件。如果现在开源的avia/mid360+camera的同步方案您在测试中发现了什么问题,麻烦您和我同步一下~
十分感谢! 我试了一下把图像时间戳+0.1s,结果确实正常了。 但这一帧是怎么错开的,还得后面再研究一下。 最开始得到采集数据的时候,时间戳如下: 当时就觉得有点不太对劲,想着图像再慢也不会慢120ms吧,现在看来果然有问题,还得重新去排查一下图像时间戳赋值的流程。
最后再次感谢您的帮助,期待FAST-LIVO2的发布!
不客气~LiDAR一般会采集完一帧之后才发出,而相机在曝光时间,isp,以及数据传输时间比较短的情况下可以看成立马就pub出去,所以收到的相机数据应该和上一帧LiDAR scan时序上比较接近,从而在共享内存里赋值成了一个时间戳。所以相机应该+0.1s才是真实的采样时间,这个也是合理的。
不客气~LiDAR一般会采集完一帧之后才发出,而相机在曝光时间,isp,以及数据传输时间比较短的情况下可以看成立马就pub出去,所以收到的相机数据应该和上一帧LiDAR scan时序上比较接近,从而在共享内存里赋值成了一个时间戳。所以相机应该+0.1s才是真实的采样时间,这个也是合理的。
您好,听了您的解释,醍醐灌顶,我也遇到了这种情况,那请教您一下,这种0.1s的错帧情况可以避免吗,因为我看您上传的数据包不存在这种问题
可以直接在相机driver里给时间戳加0.1s,这样出来的rosbag就没问题了,因为每次开机和采集这个数值都是一样的
可以直接在相机driver里给时间戳加0.1s,这样出来的rosbag就没问题了,因为每次开机和采集这个数值都是一样的
好嘞,感谢!!
您好,我在使用Fast-Livo运行你们提供的数据包 hku1.bag 时感觉效果十分惊艳,但当我尝试自己使用Mid360采集数据运行时发现达不到这种效果,下面是一些基本信息
硬件:Livox Mid360 + Flir Blackfly S BFS-U3-50S5C + STM32F103C8T6 + Jetson Orin nano
同步方案:https://github.com/sheng00125/LIV_handhold (其中,自行修改了GPRMC数据的发送部分,使其能通过Mid360的校验,并仿照其中的海康驱动在Flir的ros驱动中添加了共享内存的那部分代码)
算法:Fast-Livo(其中,修改了 avia_handler 函数,使得Mid360的数据也能读取)
配置参数:
感觉着色效果不是很理想,后面我尝试不加任何VO算法,直接拿图像帧对应的雷达帧位姿和标定参数做投影,拼起来的着色点云效果都比Fast-Livo的效果好,下面是一些对比 Fast-Livo:
仅用图像帧对应的雷达帧位姿和标定参数做投影:
也尝试过修改不同参数,但效果始终不太好,不知道使用Mid360想获得较好的效果还应该作何调整,期待您的回复~