hku-mars / FAST-LIVO

A Fast and Tightly-coupled Sparse-Direct LiDAR-Inertial-Visual Odometry (LIVO).
GNU General Public License v2.0
1.26k stars 202 forks source link

Mid360适配 #96

Open lddnb opened 5 months ago

lddnb commented 5 months ago

您好,我在使用Fast-Livo运行你们提供的数据包 hku1.bag 时感觉效果十分惊艳,但当我尝试自己使用Mid360采集数据运行时发现达不到这种效果,下面是一些基本信息

feature_extract_enable : 0
point_filter_num : 1  # 原始为2
max_iteration : 10
dense_map_enable : 1
filter_size_surf : 0.15
filter_size_map : 0.3
cube_side_length : 20
debug : 0
grid_size : 40
patch_size : 8
img_enable : 1
lidar_enable : 1
outlier_threshold : 300 # 78 100 156
ncc_en: false
ncc_thre: 0
img_point_cov : 100 # 1000
laser_point_cov : 0.001 # 0.001
cam_fx: 448.97505
cam_fy: 448.9212
cam_cx: 313.9853
cam_cy: 264.3433

common:
    lid_topic:  "/livox/lidar"
    imu_topic:  "/livox/imu"

preprocess:
    lidar_type: 1 # Livox Avia LiDAR
    scan_line: 4 # 原始为6
    blind: 0.5 # 原始为5

mapping:
    acc_cov_scale: 100
    gyr_cov_scale: 10000
    # 改成Mid360参数
    fov_degree:    360
    extrinsic_T: [ -0.011, -0.02329, 0.04412 ]
    extrinsic_R: [ 1, 0, 0,
                   0, 1, 0,
                   0, 0, 1]

camera:
    img_topic: /camera_array/cam0/image_raw
    # 相机与雷达标定后的参数 T_cam2lidar
    Rcl: [-0.02243, -0.99956, -0.01923,
         0.42635, 0.00784, -0.90452,
          0.90428, -0.02849, 0.42599]
    Pcl: [-0.03746, -0.10140, -0.04724]

感觉着色效果不是很理想,后面我尝试不加任何VO算法,直接拿图像帧对应的雷达帧位姿和标定参数做投影,拼起来的着色点云效果都比Fast-Livo的效果好,下面是一些对比 Fast-Livo: fast-livo1 fast-livo2 fast-livo3

仅用图像帧对应的雷达帧位姿和标定参数做投影: original1 original2 original3

也尝试过修改不同参数,但效果始终不太好,不知道使用Mid360想获得较好的效果还应该作何调整,期待您的回复~

xuankuzcr commented 5 months ago

hi 感谢关注! 我已经把 https://github.com/sheng00125/LIV_handhold 中的同步方案更新,之前有一些bug,您可以重新烧一下stm32的固件。另外您之前采集的bag可以发给我,我测试一下看看有什么问题。

lddnb commented 5 months ago

感谢回复! STM32的GPRMC信号发送部分我之前自己修改过,和您更新的内容差不多 图示场景bag的Google Drive链接我已发送到了您的邮箱zhengcr@connect.hku.hk,并附上了当时测试时使用的配置文件、标定文件和launch启动文件,如果还需要什么数据,或发现什么问题,请联系我 祝好

xuankuzcr commented 5 months ago

我测试了下,外参貌似在pitch角上有点问题,可以稍微注意下。同步也没什么问题,但应该是错开了一帧,相机的时间戳应该+0.1s,可以在callback函数里面实现。以下是我测试的截图和raw point的pcd文件。如果现在开源的avia/mid360+camera的同步方案您在测试中发现了什么问题,麻烦您和我同步一下~ rviz_screenshot_2024_05_31-16_06_39 rviz_screenshot_2024_05_31-16_05_35 rviz_screenshot_2024_05_31-16_06_19

xuankuzcr commented 5 months ago

pcd文件如下 https://connecthkuhk-my.sharepoint.com/:u:/g/personal/zhengcr_connect_hku_hk/EfZdgbPWyaREmB8-Br7V1pcBpAVAJi2fDWaihEqpsmAO1w?e=p6qwho

lddnb commented 5 months ago

十分感谢! 我试了一下把图像时间戳+0.1s,结果确实正常了。 但这一帧是怎么错开的,还得后面再研究一下。 最开始得到采集数据的时候,时间戳如下: 2024-05-31_18-48 当时就觉得有点不太对劲,想着图像再慢也不会慢120ms吧,现在看来果然有问题,还得重新去排查一下图像时间戳赋值的流程。

最后再次感谢您的帮助,期待FAST-LIVO2的发布!

xuankuzcr commented 5 months ago

不客气~LiDAR一般会采集完一帧之后才发出,而相机在曝光时间,isp,以及数据传输时间比较短的情况下可以看成立马就pub出去,所以收到的相机数据应该和上一帧LiDAR scan时序上比较接近,从而在共享内存里赋值成了一个时间戳。所以相机应该+0.1s才是真实的采样时间,这个也是合理的。

0ontheroad commented 1 month ago

不客气~LiDAR一般会采集完一帧之后才发出,而相机在曝光时间,isp,以及数据传输时间比较短的情况下可以看成立马就pub出去,所以收到的相机数据应该和上一帧LiDAR scan时序上比较接近,从而在共享内存里赋值成了一个时间戳。所以相机应该+0.1s才是真实的采样时间,这个也是合理的。

您好,听了您的解释,醍醐灌顶,我也遇到了这种情况,那请教您一下,这种0.1s的错帧情况可以避免吗,因为我看您上传的数据包不存在这种问题

xuankuzcr commented 1 month ago

可以直接在相机driver里给时间戳加0.1s,这样出来的rosbag就没问题了,因为每次开机和采集这个数值都是一样的

0ontheroad commented 1 month ago

可以直接在相机driver里给时间戳加0.1s,这样出来的rosbag就没问题了,因为每次开机和采集这个数值都是一样的

好嘞,感谢!!