建图时里程计飘了

[hezinan]

我使用MID-360雷达在户外一个小场景中录制了一个bag包进行测试，下面这张图是建成后的大致地图 然而我建图的起始点在实际场景中是差不多重合的，然而所建的图中Z轴方向上差了8m，如下图所示 以下是我所使用的yaml配置文件内容： `common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.0 # Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme)

preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0

mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 2.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 20 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1.0 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 360 det_range: 450.0 gravity: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # extrinsic_T: [ -0.011, -0.02329, 0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ]

publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame

pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file;

-1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames.

` 我看到在其他issue中有提到可能是“satu_acc”和“satu_gyro”这两个参数有问题，请问我应该如何调整这两个参数呢？

[FPSychotic]

Try IMU time diff to -0.009263. Try satu_acc 4.0. Detect range between 70 -40 Gravity matrix -9.800291 You have missing gravity_init matrix, check the original file in the repository.

The IMU values you can get our own with lidar_ IMU_init package, you can use the old driver and it has a mid-360 profile

Your extrinsic_T: [ -0.011, -0.02329, 0.04412 ] is wrong Change it to extrinsic_T: [ 0.011, 0.02329, -0.04412 ]

On Mon, 10 Apr 2023, 12:41 hzn, @.***> wrote:

我使用MID-360雷达在户外一个小场景中录制了一个bag包进行测试，下面这张图是建成后的大致地图 [image: Screenshot from 2023-04-10 19-27-29] https://user-images.githubusercontent.com/40159723/230894262-d00b68bd-99e8-4dd2-ab8e-5c68fce378e3.png 然而我建图的起始点在实际场景中是差不多重合的，然而所建的图中Z轴方向上差了8m，如下图所示 [image: Screenshot from 2023-04-10 16-54-07] https://user-images.githubusercontent.com/40159723/230894538-458beca1-f3cb-4c9b-af40-a1d08b9c3440.png 以下是我所使用的yaml配置文件内容： `common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.0 # Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme)

preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0

mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 2.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 20 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1.0 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 360 det_range: 450.0 gravity: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # extrinsic_T: [ -0.011, -0.02329, 0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ]

publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame

pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file;

-1 : all frames will be saved in ONE pcd file, may lead to memory crash

when having too much frames. ` 我看到在其他issue中有提到可能是“satu_acc”和“satu_gyro”这两个参数有问题，请问我应该如何调整这两个参数呢？

— Reply to this email directly, view it on GitHub https://github.com/hku-mars/Point-LIO/issues/24, or unsubscribe https://github.com/notifications/unsubscribe-auth/AITQOVBFWWDDPEWWNSMPSWTXAPWX7ANCNFSM6AAAAAAWY4PBIU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[hezinan]

Try IMU time diff to -0.009263. Try satu_acc 4.0. Detect range between 70 -40 Gravity matrix -9.800291 You have missing gravityinit matrix, check the original file in the repository. The IMU values you can get our own with lidar IMU_init package, you can use the old driver and it has a mid-360 profile Your extrinsic_T: [ -0.011, -0.02329, 0.04412 ] is wrong Change it to extrinsic_T: [ 0.011, 0.02329, -0.04412 ] … On Mon, 10 Apr 2023, 12:41 hzn, @.> wrote: 我使用MID-360雷达在户外一个小场景中录制了一个bag包进行测试，下面这张图是建成后的大致地图 [image: Screenshot from 2023-04-10 19-27-29] https://user-images.githubusercontent.com/40159723/230894262-d00b68bd-99e8-4dd2-ab8e-5c68fce378e3.png 然而我建图的起始点在实际场景中是差不多重合的，然而所建的图中Z轴方向上差了8m，如下图所示 [image: Screenshot from 2023-04-10 16-54-07] https://user-images.githubusercontent.com/40159723/230894538-458beca1-f3cb-4c9b-af40-a1d08b9c3440.png 以下是我所使用的yaml配置文件内容： common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.0 # Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme) preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0 mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 2.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 20 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1.0 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 360 det_range: 450.0 gravity: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # extrinsic_T: [ -0.011, -0.02329, 0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ] publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file; # -1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames. 我看到在其他issue中有提到可能是“satu_acc”和“satu_gyro”这两个参数有问题，请问我应该如何调整这两个参数呢？ — Reply to this email directly, view it on GitHub <#24>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AITQOVBFWWDDPEWWNSMPSWTXAPWX7ANCNFSM6AAAAAAWY4PBIU . You are receiving this because you are subscribed to this thread.Message ID: @.>

Thank you for your comment. I modified the .yaml file as you suggested, but things are not getting better. After the mapping is completed, the pose is pose: position: x: 0.36815819104531655 y: 0.678288393384465 z: -6.50272109195675 orientation: x: -0.03622187241230705 y: -0.02881759430156855 z: -0.017557230013610873 w: -0.9987738812477972 while is should end up with pose: position: x: 0 y: 0 z: 0 orientation: x: 0 y: 0 z: 0 w:1

This is my modified .yaml file： common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: -0.001792 # 0.0 Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme)

preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0

mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 30 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 9.81 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 180 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ]

odometry: publish_odometry_without_downsample: false

publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame

pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file;

-1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames.

This is Initializationresult file which generated by lidar IMU_init package: Initialization result: Rotation LiDAR to IMU (degree) = -0.834624 1.782606 -2.318998 Translation LiDAR to IMU (meter) = 0.086320 0.005521 0.009183 Time Lag IMU to LiDAR (second) = 0.001792 Bias of Gyroscope (rad/s) = -0.003128 0.008381 0.003716 Bias of Accelerometer (meters/s^2) = -0.009904 0.010262 -0.009829 Gravity in World Frame(meters/s^2) = 0.315861 -0.055738 -9.804755

Homogeneous Transformation Matrix from LiDAR to IMU: 0.998698 0.040003 0.031666 0.086320 -0.040441 0.999093 0.013295 0.005521 -0.031105 -0.014558 0.999410 0.009183 0.000000 0.000000 0.000000 1.000000

Refinement result: Rotation LiDAR to IMU (degree) = -2.391860 0.545141 -0.863348 Translation LiDAR to IMU (meter) = 0.095401 -0.001211 -0.113060 Time Lag IMU to LiDAR (second) = 0.001792 Bias of Gyroscope (rad/s) = -0.073447 -0.251035 -0.258364 Bias of Accelerometer (meters/s^2) = -0.500195 -0.396227 -1.260040 Gravity in World Frame(meters/s^2) = 0.105283 0.135222 -8.716644

Homogeneous Transformation Matrix from LiDAR to IMU: 0.999841 0.014656 0.010133 0.095401 -0.015066 0.999021 0.041583 -0.001211 -0.009514 -0.041729 0.999084 -0.113060 0.000000 0.000000 0.000000 1.000000

[Joanna-HE]

你好，

1. 请问你使用的ubuntu18.04还是ubuntu20.04呢？18.04会出现一些非代码本身造成的drift，是pcl的配置问题。
2. acc_norm这个参数请改为1.0。如果你没有对mid360的内置imu做修改的话，它的加速度计的单位是g。
3. satu_gyro请改为35。
4. time_diff_lidar_to_imu改为0.001792

再试一下呢？

[hezinan]

你好，

1. 请问你使用的ubuntu18.04还是ubuntu20.04呢？18.04会出现一些非代码本身造成的drift，是pcl的配置问题。
2. acc_norm这个参数请改为1.0。如果你没有对mid360的内置imu做修改的话，它的加速度计的单位是g。
3. satu_gyro请改为35。
4. time_diff_lidar_to_imu改为0.001792

再试一下呢？

感谢你的回复，我刚刚按照你的建议修改了一下配置文件，但是情况依然没有改观，以下是我修改后的.yaml common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.001792 # 0.0 Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme)

preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0

mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 180 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ]

odometry: publish_odometry_without_downsample: false

publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame

pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file;

-1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames.

结果依然是在Z轴方向上差很多，此链接包含我测试使用的bag包

[Joanna-HE]

我用你这封邮件中发给我的参数，跑了一下链接中的bag，回到终点时，z方向有1.4m的drift。然后把lidar_meas_cov改为0.1，z方向的drift就为0了。你可以试试看~

---

寄件者: hzn @.> 寄件日期: 2023年4月11日 下午 06:21 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; Comment @.***> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24)

你好，

1. 请问你使用的ubuntu18.04还是ubuntu20.04呢？18.04会出现一些非代码本身造成的drift，是pcl的配置问题。
2. acc_norm这个参数请改为1.0。如果你没有对mid360的内置imu做修改的话，它的加速度计的单位是g。
3. satu_gyro请改为35。
4. time_diff_lidar_to_imu改为0.001792

再试一下呢？ 感谢你的回复，我刚刚按照你的建议修改了一下配置文件，但是情况依然没有改观，以下是我修改后的.yaml common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.001792 # 0.0 Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme)

preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0

mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 180 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ]

odometry: publish_odometry_without_downsample: false

publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame

pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file;

-1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames.

结果依然是在Z轴方向上差很多，此链接https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link包含我测试使用的bag包

― Reply to this email directly, view it on GitHubhttps://github.com/hku-mars/Point-LIO/issues/24#issuecomment-1503063253, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXSFF24IXOB2O7E3VMTXAUWAZANCNFSM6AAAAAAWY4PBIU. You are receiving this because you commented.Message ID: @.***>

[FPSychotic]

I tested your .bag with my setups and Joanna-HE, non worked. My bags and realtime mapping works nice. No sure what is the problem with your bag, I tried lidar_meas_cov 0.1 and still 2m of Z drift, with my setup with 0.01 was 1.5m aprox.

EDIT I tested with fast-lio too, which also perform without issue in my setup and it fails in the same way in Z axis

I hope that helps

[hezinan]

我用你这封邮件中发给我的参数，跑了一下链接中的bag，回到终点时，z方向有1.4m的drift。然后把lidar_meas_cov改为0.1，z方向的drift就为0了。你可以试试看~ … ____ 寄件者: hzn @.> 寄件日期: 2023年4月11日 下午 06:21 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; Comment @.> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24) 你好， 1. 请问你使用的ubuntu18.04还是ubuntu20.04呢？18.04会出现一些非代码本身造成的drift，是pcl的配置问题。 2. acc_norm这个参数请改为1.0。如果你没有对mid360的内置imu做修改的话，它的加速度计的单位是g。 3. satu_gyro请改为35。 4. time_diff_lidar_to_imu改为0.001792 再试一下呢？ 感谢你的回复，我刚刚按照你的建议修改了一下配置文件，但是情况依然没有改观，以下是我修改后的.yaml common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.001792 # 0.0 Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme) preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0 mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 180 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ] odometry: publish_odometry_without_downsample: false publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file; # -1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames. 结果依然是在Z轴方向上差很多，此链接<https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link>包含我测试使用的bag包 ― Reply to this email directly, view it on GitHub<#24 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXSFF24IXOB2O7E3VMTXAUWAZANCNFSM6AAAAAAWY4PBIU. You are receiving this because you commented.Message ID: @.>

按照你的建议，我将lidar_meas_cov改为0.1后z方向的drift减小了许多，大概为1.8，我想可能与我的数据包也有关系，采集数据时我将雷达固定在自行车上，但是自行车一直很颠簸。 感谢你的帮助！

[Joanna-HE]

你的系统是ubuntu18.04吗？我将lidar_meas_cov改为0.1后，z方向就没有drift了，自行车上的颠簸应该是不会有什么影响的。

---

寄件者: hzn @.> 寄件日期: 2023年4月12日 上午 11:34 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; Comment @.***> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24)

我用你这封邮件中发给我的参数，跑了一下链接中的bag，回到终点时，z方向有1.4m的drift。然后把lidar_meas_cov改为0.1，z方向的drift就为0了。你可以试试看~ … ____ 寄件者: hzn @.> 寄件日期: 2023年4月11日 下午 06:21 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; Comment @.> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24https://github.com/hku-mars/Point-LIO/issues/24) 你好， 1. 请问你使用的ubuntu18.04还是ubuntu20.04呢？18.04会出现一些非代码本身造成的drift，是pcl的配置问题。 2. acc_norm这个参数请改为1.0。如果你没有对mid360的内置imu做修改的话，它的加速度计的单位是g。 3. satu_gyro请改为35。 4. time_diff_lidar_to_imu改为0.001792 再试一下呢？ 感谢你的回复，我刚刚按照你的建议修改了一下配置文件，但是情况依然没有改观，以下是我修改后的.yaml common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.001792 # 0.0 Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme) preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0 mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 180 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ] odometry: publish_odometry_without_downsample: false publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file; # -1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames. 结果依然是在Z轴方向上差很多，此链接https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link包含我测试使用的bag包https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link%3E%E5%8C%85%E5%90%AB%E6%88%91%E6%B5%8B%E8%AF%95%E4%BD%BF%E7%94%A8%E7%9A%84bag%E5%8C%85 D Reply to this email directly, view it on GitHub<#24 (comment)https://github.com/hku-mars/Point-LIO/issues/24#issuecomment-1503063253>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXSFF24IXOB2O7E3VMTXAUWAZANCNFSM6AAAAAAWY4PBIU. You are receiving this because you commented.Message ID: @.>

按照你的建议，我将lidar_meas_cov改为0.1后z方向的drift减小了许多，大概为1.8，我想可能与我的数据包也有关系，采集数据时我将雷达固定在自行车上，但是自行车一直很颠簸。 感谢你的帮助！

― Reply to this email directly, view it on GitHubhttps://github.com/hku-mars/Point-LIO/issues/24#issuecomment-1504531220, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXW6M3TZ7P4TST5HL5TXAYPE5ANCNFSM6AAAAAAWY4PBIU. You are receiving this because you commented.Message ID: @.***>

[Joanna-HE]

I tested your .bag with my setups and Joanna-HE, non worked. My bags and realtime mapping works nice. No sure what is the problem with your bag, I tried lidar_meas_cov 0.1 and still 2m of Z drift, with my setup with 0.01 was 1.5m aprox.

EDIT I tested with fast-lio too, which also perform without issue in my setup and it fails in the same way in Z axis

I hope that helps

try the following parameters in point-lio, I got no drift in the end. and in my test, I did not change the mapping_avia.launch file.

common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_lag_imu_to_lidar: 0.001792 # Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme)

the timesample of IMU is transferred from the current timeline to LiDAR's timeline by subtracting this value

preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0

mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1.0 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.1 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 180 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [0.011, 0.02329, -0.04412] # [ 0.04165, 0.02326, -0.0284 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ]

odometry: publish_odometry_without_downsample: false

publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame

pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file;

-1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames.

[hezinan]

你的系统是ubuntu18.04吗？我将lidar_meas_cov改为0.1后，z方向就没有drift了，自行车上的颠簸应该是不会有什么影响的。 … ____ 寄件者: hzn @.> 寄件日期: 2023年4月12日 上午 11:34 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; Comment @.> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24) 我用你这封邮件中发给我的参数，跑了一下链接中的bag，回到终点时，z方向有1.4m的drift。然后把lidar_meas_cov改为0.1，z方向的drift就为0了。你可以试试看~ … ____ 寄件者: hzn @.> 寄件日期: 2023年4月11日 下午 06:21 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; Comment @.> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24<#24>) 你好， 1. 请问你使用的ubuntu18.04还是ubuntu20.04呢？18.04会出现一些非代码本身造成的drift，是pcl的配置问题。 2. acc_norm这个参数请改为1.0。如果你没有对mid360的内置imu做修改的话，它的加速度计的单位是g。 3. satu_gyro请改为35。 4. time_diff_lidar_to_imu改为0.001792 再试一下呢？ 感谢你的回复，我刚刚按照你的建议修改了一下配置文件，但是情况依然没有改观，以下是我修改后的.yaml common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.001792 # 0.0 Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme) preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0 mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 180 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ] odometry: publish_odometry_without_downsample: false publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file; # -1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames. 结果依然是在Z轴方向上差很多，此链接<https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link>包含我测试使用的bag包<https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link%3E%E5%8C%85%E5%90%AB%E6%88%91%E6%B5%8B%E8%AF%95%E4%BD%BF%E7%94%A8%E7%9A%84bag%E5%8C%85> D Reply to this email directly, view it on GitHub<#24 (comment)<#24 (comment)>>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXSFF24IXOB2O7E3VMTXAUWAZANCNFSM6AAAAAAWY4PBIU. You are receiving this because you commented.Message ID: @.> 按照你的建议，我将lidar_meas_cov改为0.1后z方向的drift减小了许多，大概为1.8，我想可能与我的数据包也有关系，采集数据时我将雷达固定在自行车上，但是自行车一直很颠簸。 感谢你的帮助！ ― Reply to this email directly, view it on GitHub<#24 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXW6M3TZ7P4TST5HL5TXAYPE5ANCNFSM6AAAAAAWY4PBIU. You are receiving this because you commented.Message ID: @.>

我的系统是20.04，我又跑了几遍录制的包，发现每一次的结果都有些不一样

第一次在y方向偏移了71cm

第二次在x方向偏移了87cm

第三次结果很完美，起始点大致重合

[Joanna-HE]

这个随机性有可能是Eigen库的quaternion导致的，我对这部分做了修改，推送到了新的commit里，可以试试。

[FPSychotic]

这个随机性有可能是Eigen库的quaternion导致的，我对这部分做了修改，推送到了新的commit里，可以试试。

With that commit my mapping always crash, start to get crazy in some point, with the post bags, but also with my own ones. With my setup, without the new commit and the values in the .yalm you said to tests, it still will drift and with lidar_meas_cov: 0.1. always will get crazy, as the commit. Could be because I modified Point-Lio package to work with the livox_ros_driver2? , maybe you are using the stock point-lio with the livox_ros_driver. I modified the calls to livox_ros_driver::custom_msg by livox_ros_driver2::custom_msg and everything is working nice in my side, but it looks it make some difference with other bags, maybe how both drivers works with the gravity units, maybe I should modify in point_lio the gravity units . But as resume, the new commit doesnt work for me and the post .bag will drift with any setup, but my realtime mapping and bags will work. What livox driver do you use for mid-360? How you made work point-lio with mid-360?

[hezinan]

这个随机性有可能是Eigen库的quaternion导致的，我对这部分做了修改，推送到了新的commit里，可以试试。

我试了一下你们最新发布的代码，运行结果随机性的问题还是存在

[weixiaopassking]

这个随机性有可能是Eigen库的quaternion导致的，我对这部分做了修改，推送到了新的commit里，可以试试。 这个Eigen库的quaternion导致随机性的具体原因大概是什么呢？浮点问题？

[Joanna-HE]

我在我的系统配置下是没有随机性的，我猜测的Eigen库quaternion的随机性，在于quaternion的归一化上，quaternion在计算时，会因为浮点精度，导致归一化有问题，就可能不是一个旋转变换了。

---

寄件者: michael coffee @.> 寄件日期: 2023年4月17日 下午 04:08 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; Comment @.***> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24)

这个随机性有可能是Eigen库的quaternion导致的，我对这部分做了修改，推送到了新的commit里，可以试试。 这个Eigen库的quaternion导致随机性的具体原因大概是什么呢？浮点问题？

― Reply to this email directly, view it on GitHubhttps://github.com/hku-mars/Point-LIO/issues/24#issuecomment-1510894339, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXXOUZ4BLZFJJIOKZX3XBT3AVANCNFSM6AAAAAAWY4PBIU. You are receiving this because you commented.Message ID: @.***>

[98huan]

Try IMU time diff to -0.009263. Try satu_acc 4.0. Detect range between 70 -40 Gravity matrix -9.800291 You have missing gravityinit matrix, check the original file in the repository. The IMU values you can get our own with lidar IMU_init package, you can use the old driver and it has a mid-360 profile Your extrinsic_T: [ -0.011, -0.02329, 0.04412 ] is wrong Change it to extrinsic_T: [ 0.011, 0.02329, -0.04412 ] … On Mon, 10 Apr 2023, 12:41 hzn, @.> wrote: 我使用MID-360雷达在户外一个小场景中录制了一个bag包进行测试，下面这张图是建成后的大致地图 [image: Screenshot from 2023-04-10 19-27-29] https://user-images.githubusercontent.com/40159723/230894262-d00b68bd-99e8-4dd2-ab8e-5c68fce378e3.png 然而我建图的起始点在实际场景中是差不多重合的，然而所建的图中Z轴方向上差了8m，如下图所示 [image: Screenshot from 2023-04-10 16-54-07] https://user-images.githubusercontent.com/40159723/230894538-458beca1-f3cb-4c9b-af40-a1d08b9c3440.png 以下是我所使用的yaml配置文件内容： common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.0 # Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme) preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0 mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 2.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 20 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1.0 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 360 det_range: 450.0 gravity: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # extrinsic_T: [ -0.011, -0.02329, 0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ] publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file; # -1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames. 我看到在其他issue中有提到可能是“satu_acc”和“satu_gyro”这两个参数有问题，请问我应该如何调整这两个参数呢？ — Reply to this email directly, view it on GitHub <#24>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AITQOVBFWWDDPEWWNSMPSWTXAPWX7ANCNFSM6AAAAAAWY4PBIU . You are receiving this because you are subscribed to this thread.Message ID: @.> Hello, what makes me wonder is why extrinsic_T is wrong, the extrinsic_T in the paper is Lidar pose in IMU, so i think it means imu is base frame, If I am wrong, please correct me.

[FPSychotic]

Nothing make think that values are negatives, not sure if they had the lidar inverted in a drone in example. Having the lidar in normal position in my understanding it should have the values written in the mid-360 manual, is what I did, and it works for me form first time and everything is coherent

On Fri, 21 Apr 2023, 17:54 98huan, @.***> wrote:

Try IMU time diff to -0.009263. Try satu_acc 4.0. Detect range between 70 -40 Gravity matrix -9.800291 You have missing gravityinit matrix, check the original file in the repository. The IMU values you can get our own with lidar IMU_init package, you can use the old driver and it has a mid-360 profile Your extrinsic_T: [ -0.011, -0.02329, 0.04412 ] is wrong Change it to extrinsic_T: [ 0.011, 0.02329, -0.04412 ] … <#m589117371825096089> On Mon, 10 Apr 2023, 12:41 hzn, @.> wrote: 我使用MID-360雷达在户外一个小场景中录制了一个bag包进行测试，下面这张图是建成后的大致地图 [image: Screenshot from 2023-04-10 19-27-29] https://user-images.githubusercontent.com/40159723/230894262-d00b68bd-99e8-4dd2-ab8e-5c68fce378e3.png https://user-images.githubusercontent.com/40159723/230894262-d00b68bd-99e8-4dd2-ab8e-5c68fce378e3.png 然而我建图的起始点在实际场景中是差不多重合的，然而所建的图中Z轴方向上差了8m，如下图所示 [image: Screenshot from 2023-04-10 16-54-07] https://user-images.githubusercontent.com/40159723/230894538-458beca1-f3cb-4c9b-af40-a1d08b9c3440.png https://user-images.githubusercontent.com/40159723/230894538-458beca1-f3cb-4c9b-af40-a1d08b9c3440.png 以下是我所使用的yaml配置文件内容： common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.0 # Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme) preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0 mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 2.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 20 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1.0 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 360 det_range: 450.0 gravity: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # extrinsic_T: [ -0.011, -0.02329, 0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ] publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file; # -1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames. 我看到在其他issue中有提到可能是“satu_acc”和“satu_gyro”这两个参数有问题，请问我应该如何调整这两个参数呢？ — Reply to this email directly, view it on GitHub <#24 https://github.com/hku-mars/Point-LIO/issues/24>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AITQOVBFWWDDPEWWNSMPSWTXAPWX7ANCNFSM6AAAAAAWY4PBIU https://github.com/notifications/unsubscribe-auth/AITQOVBFWWDDPEWWNSMPSWTXAPWX7ANCNFSM6AAAAAAWY4PBIU . You are receiving this because you are subscribed to this thread.Message ID: @.> Hello, what makes me wonder is why extrinsic_T is wrong, the extrinsic_T in the paper is Lidar pose in IMU, so i think it means imu is base frame, If I am wrong, please correct me. [image: 2023-04-22 00-49-55 的屏幕截图] https://user-images.githubusercontent.com/74247646/233691625-783f6ce6-c34f-4ce4-9eed-827864897480.png

— Reply to this email directly, view it on GitHub https://github.com/hku-mars/Point-LIO/issues/24#issuecomment-1518097222, or unsubscribe https://github.com/notifications/unsubscribe-auth/AITQOVBMM6IIBWUQJCN7BO3XCK3SVANCNFSM6AAAAAAWY4PBIU . You are receiving this because you commented.Message ID: @.***>

[FPSychotic]

I did complement my previous tests with a second setup in a different computer. My setup 1, the one used in my previous comments, is Point-lio modified to use livox_ros_driver2. On it , with any option I changed ( the new commit to fix the random results crash ), always finished with 2m of Z drift in the @98huan bag, but worked nicely in my own bags or real time. The onlyoption I didn't change was the -0.009 of the IMU Delay given by the Lidar_IMU_init package.

My setup 2, in this setup I changed the way I installed Point-Lio , I installed it with the old driver, with not modification in point-lio, but instead run the new driver. I setup the files as @Joanna-HE advised, including IMU delay, which curiously is very different to the mine as it is a positive value, 0.001xx but mine is negative -0.009, so maybe something wrong there as it means one of the two IMU data arrive faster than lidar points, quite weird that variation from positive to negative, anyways it worked nicely and in two tests, both finished perfect in Z axis, 0.000x .

Now my question for @Joanna-HE is what is the right for IMU delay , positive as your 0.001 or negative as my -0.009x value, imu_int package never gave me a positive value, is there any change in the code or in the package that needs change from negative to positive?

I'm going to run another tests with my setup1 with you positive value to see if it is the reason of 2m in Z. I will update with the results

[Joanna-HE]

Hi, thanks for your test on the Point-LIO!

In our tests, we install the livox_ros_driver2.0, and do not encounter the random problems. Maybe this random problem is caused by other sources. The most possible causes are Eigen version and the PCL version. For the IMU delay with respect to the lidar, it is the same value of that calibrated by LI-Init. And if this value is not determined, 0.0 is recommended.

---

寄件者: FPSychotic @.> 寄件日期: 2023年4月23日 上午 03:03 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; Mention @.***> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24)

I did complemented my previous tests with a second setup in a different computer. My setup 1, the one used in my previous comments, is Point-lio modified to use livox_ros_driver2. On it , with any setup I changed or even with the new commit to fix the random results, always finished with 2m of Z drift in the @98huanhttps://github.com/98huan bag but worked nicely in my own bags or real time. The only thing I didn't change was the -0.009 of the IMU Delay given by the Lidar_IMU_init package.

My setup 2, in this changes the way I installed Point-Lio , I installed it with the old driver, not modification, but instead run the old driver. I setup all the changes @Joanna-HEhttps://github.com/Joanna-HE adviced, including IMU delay, that curiously is very different to the mine as it is positive value, 0.001xx but mine is negative -0.009, so something wrong there. In one of the two IMU data arrive faster than lidar points, anyways it worked nicely and in two tests, both finished perfect in Z axis, 0.000x . [IMG_20230422_193533]https://user-images.githubusercontent.com/36112212/233801929-5eb29114-3875-4f38-92bd-b094e710e2a0.jpg [IMG_20230422_191640]https://user-images.githubusercontent.com/36112212/233801930-151224d5-8d7d-46b8-b26e-fd7efbcb0a1c.jpg

Now my question for @Joanna-HEhttps://github.com/Joanna-HE is what is the right for IMU delay , positive as your 0.001 or negative as my -0.009x value?

I'm going to run another tests with my setup1 with you positive value to see if it is the reason of 2m in Z. I will update with the results

― Reply to this email directly, view it on GitHubhttps://github.com/hku-mars/Point-LIO/issues/24#issuecomment-1518734590, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXW7JK5JWDQIPPAIIKLXCQTQDANCNFSM6AAAAAAWY4PBIU. You are receiving this because you were mentioned.Message ID: @.***>

[Joanna-HE]

Hi, the random problems may be triggered not by the ubuntu version, or the Eigen/PCL version, it is redulted from the ikdtree, that has a rebuild process in the second thread! I will make sure about this problem as soon as possible.

[Joanna-HE]

这个随机性有可能是Eigen库的quaternion导致的，我对这部分做了修改，推送到了新的commit里，可以试试。

With that commit my mapping always crash, start to get crazy in some point, with the post bags, but also with my own ones. With my setup, without the new commit and the values in the .yalm you said to tests, it still will drift and with lidar_meas_cov: 0.1. always will get crazy, as the commit. Could be because I modified Point-Lio package to work with the livox_ros_driver2? , maybe you are using the stock point-lio with the livox_ros_driver. I modified the calls to livox_ros_driver::custom_msg by livox_ros_driver2::custom_msg and everything is working nice in my side, but it looks it make some difference with other bags, maybe how both drivers works with the gravity units, maybe I should modify in point_lio the gravity units . But as resume, the new commit doesnt work for me and the post .bag will drift with any setup, but my realtime mapping and bags will work. What livox driver do you use for mid-360? How you made work point-lio with mid-360?

Hi, please try the newest commit of the master branch, in which more points are added into the ikdtree map. I hope that the crash problem could be solved.

[Joanna-HE]

你的系统是ubuntu18.04吗？我将lidar_meascov改为0.1后，z方向就没有drift了，自行车上的颠簸应该是不会有什么影响的。 … ____ 寄件者: hzn @.> 寄件日期: 2023年4月12日 上午 11:34 收件者: hku-mars/Point-LIO _@_.> 副本: @.*** @.>; Comment _@_._> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24) 我用你这封邮件中发给我的参数，跑了一下链接中的bag，回到终点时，z方向有1.4m的drift。然后把lidar_meas_cov改为0.1，z方向的drift就为0了。你可以试试看~ … ____ 寄件者: hzn @.> 寄件日期: 2023年4月11日 下午 06:21 收件者: hku-mars/Point-LIO @.> 副本: @.* @.>; Comment @.> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24<#24>) 你好， 1. 请问你使用的ubuntu18.04还是ubuntu20.04呢？18.04会出现一些非代码本身造成的drift，是pcl的配置问题。 2. acc_norm这个参数请改为1.0。如果你没有对mid360的内置imu做修改的话，它的加速度计的单位是g。 3. satu_gyro请改为35。 4. time_diff_lidar_to_imu改为0.001792 再试一下呢？ 感谢你的回复，我刚刚按照你的建议修改了一下配置文件，但是情况依然没有改观，以下是我修改后的.yaml common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_diff_lidar_to_imu: 0.001792 # 0.0 Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme) preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0 mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.01 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 180 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.800291] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ] odometry: publish_odometry_without_downsample: false publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file; # -1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames. 结果依然是在Z轴方向上差很多，此链接<https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link>包含我测试使用的bag包[https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link%3E%E5%8C%85%E5%90%AB%E6%88%91%E6%B5%8B%E8%AF%95%E4%BD%BF%E7%94%A8%E7%9A%84bag%E5%8C%85](https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link D Reply to this email directly, view it on GitHub<#24 (comment)<#24 (comment)>>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXSFF24IXOB2O7E3VMTXAUWAZANCNFSM6AAAAAAWY4PBIU. You are receiving this because you commented.Message ID: @._> 按照你的建议，我将lidar_meascov改为0.1后z方向的drift减小了许多，大概为1.8，我想可能与我的数据包也有关系，采集数据时我将雷达固定在自行车上，但是自行车一直很颠簸。 感谢你的帮助！ ― Reply to this email directly, view it on GitHub<#24 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXW6M3TZ7P4TST5HL5TXAYPE5ANCNFSM6AAAAAAWY4PBIU. You are receiving this because you commented.Message ID: @.**>

我的系统是20.04，我又跑了几遍录制的包，发现每一次的结果都有些不一样

第一次在y方向偏移了71cm

第二次在x方向偏移了87cm

第三次结果很完美，起始点大致重合

欢迎尝试一下的最新的commit，应该不会有随机性了

[hezinan]

这个随机性有可能是Eigen库的quaternion导致的，我对这部分做了修改，推送到了新的commit里，可以试试。

With that commit my mapping always crash, start to get crazy in some point, with the post bags, but also with my own ones. With my setup, without the new commit and the values in the .yalm you said to tests, it still will drift and with lidar_meas_cov: 0.1. always will get crazy, as the commit. Could be because I modified Point-Lio package to work with the livox_ros_driver2? , maybe you are using the stock point-lio with the livox_ros_driver. I modified the calls to livox_ros_driver::custom_msg by livox_ros_driver2::custom_msg and everything is working nice in my side, but it looks it make some difference with other bags, maybe how both drivers works with the gravity units, maybe I should modify in point_lio the gravity units . But as resume, the new commit doesnt work for me and the post .bag will drift with any setup, but my realtime mapping and bags will work. What livox driver do you use for mid-360? How you made work point-lio with mid-360?

Hi, please try the newest commit of the master branch, in which more points are added into the ikdtree map. I hope that the crash problem could be solved.

我尝试了一下最新的commit，发现依然有随机性存在，使用的数据依然是这个，但是这次只有两种情况，要么结果正确，要么Z轴方向偏差1m，我统计了十次的结果如下（其中4次正确，6次偏离），理想情况下x=0,y=0,z=0

1. position: x: -0.07496037004287397 y: 0.04195156373794468 z: -1.1016957736300275 orientation: x: -0.0070320074729810405 y: -0.0071791457941716265 z: -0.015171796989307281 w: -0.999834399935324
2. position: x: -0.011182189535943033 y: -0.019528817807165585 z: -1.0455203139613676 orientation: x: -0.005998942744598608 y: -0.006395500728589181 z: -0.016410281504375124 w: -0.9998268914663483
3. position: x: -0.018976494942950436 y: -0.036772071659919615 z: -0.9984910426451183 orientation: x: -0.005203744886299105 y: -0.006281383544689568 z: -0.01628939145629854 w: -0.9998340467142497
4. position: x: -0.026828064240220245 y: -0.032474576288038993 z: 0.00572134235166279 orientation: x: -0.00542818759813699 y: -0.00351312186936211 z: -0.01585037810238338 w: -0.9998534683890327
5. position: x: -0.06305685429665434 y: 0.04386963974198102 z: -1.4217356733566657 orientation: x: -0.007529400161042285 y: -0.0062143045298910125 z: -0.01560159930488576 w: -0.999830625972438
6. position: x: -0.02836179992614243 y: -0.029697659828758147 z: 0.01084062294543336 orientation: x: -0.005089559841432155 y: -0.003554548737274606 z: -0.015629399960562416 w: -0.9998585817018153
7. position: x: -0.07496037004287397 y: 0.04195156373794468 z: -1.1016957736300275 orientation: x: -0.0070320074729810405 y: -0.0071791457941716265 z: -0.015171796989307281 w: -0.9998343999353245
8. position: x: -0.026012491893384986 y: -0.02882643368952773 z: 0.00687621593406567 orientation: x: -0.0054562021615693545 y: -0.0033591838128402885 z: -0.01579193345585789 w: -0.9998547697346853
9. position: x: -0.022711150821504846 y: -0.02806810136197073 z: 0.005971762405678596 orientation: x: -0.005454911463581935 y: -0.0036172689752469347 z: -0.015808504850306597 w: -0.9998536145165151
10. position: x: 0.008907590463635323 y: 0.12616990877220136 z: -1.1975205255052912 orientation: x: -0.007424775490511493 y: -0.006289431110477759 z: -0.015420986825995502 w: -0.9998337406353376

使用的.yaml文件如下： common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_lag_imu_to_lidar: 0.0 # Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme)

the timesample of IMU is transferred from the current timeline to LiDAR's timeline by subtracting this value

preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0

mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1.0 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.1 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 60 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ]

odometry: publish_odometry_without_downsample: false

publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame

pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file;

-1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames.

[Joanna-HE]

你好，感谢你的测试。我目前的分析，认为造成随机性的唯一可能性就是在最邻近搜索时，从地图（ikdtree）中搜到的雷达点，会因为电脑的当时的状态而有所不同。因为ikdtree在第二线程中有一个重建的过程。

邮件中的结果是倍速播放bag时的结果吗？尝试一下正常速率播放bag，随机性会减少很多。

---

寄件者: hzn @.> 寄件日期: 2023年5月22日 下午 08:34 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; State change @.***> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24)

这个随机性有可能是Eigen库的quaternion导致的，我对这部分做了修改，推送到了新的commit里，可以试试。

With that commit my mapping always crash, start to get crazy in some point, with the post bags, but also with my own ones. With my setup, without the new commit and the values in the .yalm you said to tests, it still will drift and with lidar_meas_cov: 0.1. always will get crazy, as the commit. Could be because I modified Point-Lio package to work with the livox_ros_driver2? , maybe you are using the stock point-lio with the livox_ros_driver. I modified the calls to livox_ros_driver::custom_msg by livox_ros_driver2::custom_msg and everything is working nice in my side, but it looks it make some difference with other bags, maybe how both drivers works with the gravity units, maybe I should modify in point_lio the gravity units . But as resume, the new commit doesnt work for me and the post .bag will drift with any setup, but my realtime mapping and bags will work. What livox driver do you use for mid-360? How you made work point-lio with mid-360?

Hi, please try the newest commit of the master branch, in which more points are added into the ikdtree map. I hope that the crash problem could be solved.

我尝试了一下最新的commit，发现依然有随机性存在，使用的数据依然是这个https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link，但是这次只有两种情况，要么结果正确，要么Z轴方向偏差1m，我统计了十次的结果如下，理想情况下x=0,y=0,z=0

1.

position:

x: -0.07496037004287397 y: 0.04195156373794468 z: -1.1016957736300275 orientation: x: -0.0070320074729810405 y: -0.0071791457941716265 z: -0.015171796989307281 w: -0.999834399935324 2.

position:

x: -0.011182189535943033 y: -0.019528817807165585 z: -1.0455203139613676 orientation: x: -0.005998942744598608 y: -0.006395500728589181 z: -0.016410281504375124 w: -0.9998268914663483 3.

position:

x: -0.018976494942950436 y: -0.036772071659919615 z: -0.9984910426451183 orientation: x: -0.005203744886299105 y: -0.006281383544689568 z: -0.01628939145629854 w: -0.9998340467142497 4.

position:

x: -0.026828064240220245 y: -0.032474576288038993 z: 0.00572134235166279 orientation: x: -0.00542818759813699 y: -0.00351312186936211 z: -0.01585037810238338 w: -0.9998534683890327 5.

position:

x: -0.06305685429665434 y: 0.04386963974198102 z: -1.4217356733566657 orientation: x: -0.007529400161042285 y: -0.0062143045298910125 z: -0.01560159930488576 w: -0.999830625972438 6.

position:

x: -0.02836179992614243 y: -0.029697659828758147 z: 0.01084062294543336 orientation: x: -0.005089559841432155 y: -0.003554548737274606 z: -0.015629399960562416 w: -0.9998585817018153

7. position: x: -0.07496037004287397 y: 0.04195156373794468 z: -1.1016957736300275 orientation: x: -0.0070320074729810405 y: -0.0071791457941716265 z: -0.015171796989307281 w: -0.9998343999353245

position:

x: -0.026012491893384986 y: -0.02882643368952773 z: 0.00687621593406567 orientation: x: -0.0054562021615693545 y: -0.0033591838128402885 z: -0.01579193345585789 w: -0.9998547697346853 9.

position:

x: -0.022711150821504846 y: -0.02806810136197073 z: 0.005971762405678596 orientation: x: -0.005454911463581935 y: -0.0036172689752469347 z: -0.015808504850306597 w: -0.9998536145165151 10.

position:

x: 0.008907590463635323 y: 0.12616990877220136 z: -1.1975205255052912 orientation: x: -0.007424775490511493 y: -0.006289431110477759 z: -0.015420986825995502 w: -0.9998337406353376

使用的.yaml文件如下： common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_lag_imu_to_lidar: 0.0 # Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme)

the timesample of IMU is transferred from the current timeline to LiDAR's timeline by subtracting this value

preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0

mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1.0 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.1 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 60 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ]

odometry: publish_odometry_without_downsample: false

publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame

pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file;

-1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames.

― Reply to this email directly, view it on GitHubhttps://github.com/hku-mars/Point-LIO/issues/24#issuecomment-1557141766, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXQVGORA7LGHQM6OWADXHNMM3ANCNFSM6AAAAAAWY4PBIU. You are receiving this because you modified the open/close state.Message ID: @.***>

[hezinan]

你好，感谢你的测试。我目前的分析，认为造成随机性的唯一可能性就是在最邻近搜索时，从地图（ikdtree）中搜到的雷达点，会因为电脑的当时的状态而有所不同。因为ikdtree在第二线程中有一个重建的过程。 邮件中的结果是倍速播放bag时的结果吗？尝试一下正常速率播放bag，随机性会减少很多。 … ____ 寄件者: hzn @.> 寄件日期: 2023年5月22日 下午 08:34 收件者: hku-mars/Point-LIO @.> 副本: @. @.>; State change @.> 主旨: Re: [hku-mars/Point-LIO] 建图时里程计飘了 (Issue #24) 这个随机性有可能是Eigen库的quaternion导致的，我对这部分做了修改，推送到了新的commit里，可以试试。 With that commit my mapping always crash, start to get crazy in some point, with the post bags, but also with my own ones. With my setup, without the new commit and the values in the .yalm you said to tests, it still will drift and with lidar_meas_cov: 0.1. always will get crazy, as the commit. Could be because I modified Point-Lio package to work with the livox_ros_driver2? , maybe you are using the stock point-lio with the livox_ros_driver. I modified the calls to livox_ros_driver::custom_msg by livox_ros_driver2::custom_msg and everything is working nice in my side, but it looks it make some difference with other bags, maybe how both drivers works with the gravity units, maybe I should modify in point_lio the gravity units . But as resume, the new commit doesnt work for me and the post .bag will drift with any setup, but my realtime mapping and bags will work. What livox driver do you use for mid-360? How you made work point-lio with mid-360? Hi, please try the newest commit of the master branch, in which more points are added into the ikdtree map. I hope that the crash problem could be solved. 我尝试了一下最新的commit，发现依然有随机性存在，使用的数据依然是这个<https://drive.google.com/file/d/1eeSqeG9Oj0RZQrx2TqWeW35vKfsvNfzT/view?usp=share_link>，但是这次只有两种情况，要么结果正确，要么Z轴方向偏差1m，我统计了十次的结果如下，理想情况下x=0,y=0,z=0 1. position: x: -0.07496037004287397 y: 0.04195156373794468 z: -1.1016957736300275 orientation: x: -0.0070320074729810405 y: -0.0071791457941716265 z: -0.015171796989307281 w: -0.999834399935324 2. position: x: -0.011182189535943033 y: -0.019528817807165585 z: -1.0455203139613676 orientation: x: -0.005998942744598608 y: -0.006395500728589181 z: -0.016410281504375124 w: -0.9998268914663483 3. position: x: -0.018976494942950436 y: -0.036772071659919615 z: -0.9984910426451183 orientation: x: -0.005203744886299105 y: -0.006281383544689568 z: -0.01628939145629854 w: -0.9998340467142497 4. position: x: -0.026828064240220245 y: -0.032474576288038993 z: 0.00572134235166279 orientation: x: -0.00542818759813699 y: -0.00351312186936211 z: -0.01585037810238338 w: -0.9998534683890327 5. position: x: -0.06305685429665434 y: 0.04386963974198102 z: -1.4217356733566657 orientation: x: -0.007529400161042285 y: -0.0062143045298910125 z: -0.01560159930488576 w: -0.999830625972438 6. position: x: -0.02836179992614243 y: -0.029697659828758147 z: 0.01084062294543336 orientation: x: -0.005089559841432155 y: -0.003554548737274606 z: -0.015629399960562416 w: -0.9998585817018153 7. position: x: -0.07496037004287397 y: 0.04195156373794468 z: -1.1016957736300275 orientation: x: -0.0070320074729810405 y: -0.0071791457941716265 z: -0.015171796989307281 w: -0.9998343999353245 8. position: x: -0.026012491893384986 y: -0.02882643368952773 z: 0.00687621593406567 orientation: x: -0.0054562021615693545 y: -0.0033591838128402885 z: -0.01579193345585789 w: -0.9998547697346853 9. position: x: -0.022711150821504846 y: -0.02806810136197073 z: 0.005971762405678596 orientation: x: -0.005454911463581935 y: -0.0036172689752469347 z: -0.015808504850306597 w: -0.9998536145165151 10. position: x: 0.008907590463635323 y: 0.12616990877220136 z: -1.1975205255052912 orientation: x: -0.007424775490511493 y: -0.006289431110477759 z: -0.015420986825995502 w: -0.9998337406353376 使用的.yaml文件如下： common: lid_topic: "/livox/lidar" imu_topic: "/livox/imu" con_frame: false # true: if you need to combine several LiDAR frames into one con_frame_num: 1 # the number of frames combined cut_frame: false # true: if you need to cut one LiDAR frame into several subframes cut_frame_time_interval: 0.1 # should be integral fraction of 1 / LiDAR frequency time_lag_imu_to_lidar: 0.0 # Time offset between LiDAR and IMU calibrated by other algorithms, e.g., LI-Init (find in Readme) # the timesample of IMU is transferred from the current timeline to LiDAR's timeline by subtracting this value preprocess: lidar_type: 1 scan_line: 6 timestamp_unit: 1 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond. blind: 1.0 mapping: imu_en: true extrinsic_est_en: false # for aggressive motion, set this variable false imu_time_inte: 0.005 # = 1 / frequency of IMU satu_acc: 4.0 # the saturation value of IMU's acceleration. not related to the units satu_gyro: 35 # the saturation value of IMU's angular velocity. not related to the units acc_norm: 1.0 # 1.0 for g as unit, 9.81 for m/s^2 as unit of the IMU's acceleration lidar_meas_cov: 0.1 # 0.001; 0.01 acc_cov_output: 500 gyr_cov_output: 1000 b_acc_cov: 0.0001 b_gyr_cov: 0.0001 imu_meas_acc_cov: 0.1 #0.1 # 0.1 imu_meas_omg_cov: 0.1 #0.01 # 0.1 gyr_cov_input: 0.01 # for IMU as input model acc_cov_input: 0.1 # for IMU as input model plane_thr: 0.1 # 0.05, the threshold for plane criteria, the smaller, the flatter a plane match_s: 81 fov_degree: 60 det_range: 50.0 gravity_align: true # true to align the z axis of world frame with the direction of gravity, and the gravity direction should be specified below gravity: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # gravity to be aligned gravity_init: [0.0, 0.0, -9.810] # [0.0, 9.810, 0.0] # # preknown gravity in the first IMU body frame, use when imu_en is false or start from a non-stationary state extrinsic_T: [ 0.011, 0.02329, -0.04412 ] extrinsic_R: [ 1, 0, 0, 0, 1, 0, 0, 0, 1 ] odometry: publish_odometry_without_downsample: false publish: path_en: true # false: close the path output scan_publish_en: true # false: close all the point cloud output scan_bodyframe_pub_en: false # true: output the point cloud scans in IMU-body-frame pcd_save: pcd_save_en: false interval: -1 # how many LiDAR frames saved in each pcd file; # -1 : all frames will be saved in ONE pcd file, may lead to memory crash when having too much frames. ― Reply to this email directly, view it on GitHub<#24 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANJUIXQVGORA7LGHQM6OWADXHNMM3ANCNFSM6AAAAAAWY4PBIU. You are receiving this because you modified the open/close state.Message ID: @.>

感谢您的回复，我在几个不同的平台，包括arm核心板上也测试了一下，发现和算力也有关系，在室内的效果非常好，只是在室外远距离下有漂移，已经是目前开源里效果最好的里程计之一了，感谢您的工作！

[hr2894235132]

@hezinan 您好，请问您测试过速度较快的场景吗，我在较快速度（大约为12m/s）的场景下x出现比较大的偏差。

[hr2894235132]

@FPSychotic Hello, have you tested the fast speed scene, I have a relatively large deviation in the fast speed (about 12m/s) scenario.

[FPSychotic]

@FPSychotic Hello, have you tested the fast speed scene, I have a relatively large deviation in the fast speed (about 12m/s) scenario.

No , I just use it in a handheld scanner and a rover. They move slow. Maybe your computer is not enough powerful? Is known computer power will affect. Also I could find point lio is not very friendly of Fast-lio recorded bags, randomly some work good others give a much larger drift in Z axis. But in my real equipment it works very good. I'm sorry cannot give you better feedback. If I get time will try that bag, I guess is here in this repository.

Basically, I assume you need high CPU performance and very good synchronization.

[hr2894235132]

@FPSychotic Hello, have you tested the fast speed scene, I have a relatively large deviation in the fast speed (about 12m/s) scenario.

No , I just use it in a handheld scanner and a rover. They move slow. Maybe your computer is not enough powerful? Is known computer power will affect. Also I could find point lio is not very friendly of Fast-lio recorded bags, randomly some work good others give a much larger drift in Z axis. But in my real equipment it works very good. I'm sorry cannot give you better feedback. If I get time will try that bag, I guess is here in this repository.

Basically, I assume you need high CPU performance and very good synchronization.

Thank you very much for your reply, my CPU is i7-12700,If you have time, I don't know if you can try my bag, which is 500MB in size.Here is my bag file: https://drive.google.com/file/d/1ITqe8yMPlxW2UKkpD2cTl5Mjzq_Jjx7T/view?usp=drive_link best wishes!