hku-mars / point-lio Goto Github PK

@Joanna-HE

Thanks for sharing a great project! 😄
I have some questions about setting parameters in the config file.

I understand that saturation values are used in the h_model_IMU_output() function.
Is there any tip to set these values when applying to a custom dataset?
What kind of information should I look at from the IMU to determine the saturation value?

Also, I understand that acc_cov_output and gyr_cov_output are related to the noise covariance matrix.
What is the impact on Odometry if these values are large?
Is there a reason why 500 and 1000 are the defaults?

Thanks again for sharing awesome work, and I look forward to your response.

你好，我修改了mapping_velody16.launch文件中的pcd_save_en的参数为true。当我成功建图并结束终端后，终端提示以下图中的报错信息，Point-LIO文件夹中也没有生成PCD文件夹，想请问一下这种问题如何解决，谢谢。

自己录的horizon数据包，雷达发送频率为10Hz，单次运行时间在1.3s左右，主要是ICP部分时间异常长。
数据包链接为https://hiylkkhewk.feishu.cn/file/ZN2lbiJMIoTGCSxrFJZc0IcYnWe

The work on Point-LIO is truly impressive, elevating lidar SLAM to an entirely new level. I have some questions about this work and hope the authors can address them.

1. I've noticed that the default value for the space_down_sample parameter is true, which means the point cloud in the map generated when the Lidar is static will concentrate in the central grid area. However, when the space_down_sample parameter is set to false, the speed of mapping becomes very slow, making real-time operation impossible. I'd like to know which specific part of the algorithm is causing this slowdown? Is it possible to only use the downsampled points for calculating the Lidar position, but still add all points to the map?

2. Is the point_filter_num parameter the one that controls the number of points included in the calculation? When point_filter_num is set to 3, only 33.3% of the points are involved in the computation. But I've observed that when space_down_sample is set to false, any value of point_filter_num other than 0 makes mapping not working, with no point cloud or odometry output.

Thank you for your time and assistance.

Hi，author! Thanks for your great work.When I run your code with my datasets, the following content appears. It remained at 67% until the end of the dataset play, accompanied by a big drift.

能告诉我是哪里存在环境问题吗？我想在使用的时候自行修改。
Can you tell me where there is an environmental problem? I want to modify it myself when I use it.

你好，我们测试您的算法遇到这样一个问题，我们通过修改blind的值，以及初始化blind(0.01)的值，都没有起到雷达点云的屏蔽作用，按理说修改blind的值，点云会自动屏蔽以blind为半径的点，但是无论我们怎样修改，都没见到任何效果，可以告知原因吗；但是对于fast lio，修改blind，能起到很好的屏蔽作用

运行该算法的时候，在某一时刻突然卡住，然后就会“起飞”，请问是什么原因呢

目前我掌握的信息显示：对于一个无人机自主导航系统来说，无人机控制需要里程计的频率应该越高越好。作者在自主无人机自主导航系统中测试过该算法吗？从理论上来说该算法很适合用到高速运动的无人机的实时定位上，不知道我的理解是否有错误？

My LiDAR is velodyne 16 and all the point sample time are nagative (about -100~0 ms). That means the cloud header.stamp is the end time of the frame? I found that many other sample time is positive from open source. It confuses me a lot and I want to know the stamp whether is the begin time or the end time of the frame, so that I can change the code. Hoping for your reply! Thank you so much!

I modified the code to the following:
if (imu_en){
p_imu->Process(Measures, feats_undistort);
} else {
// p_imu->imu_need_init_ = false;
p_imu->Process(Measures, feats_undistort);
}
but i got a messy map.

我使用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”这两个参数有问题，请问我应该如何调整这两个参数呢？

请问我的地图构建为什么会是这种？看起来像点阵式一样，我使用的mid360，这是什么问题呢？

你好 我在代码看在预测时候 input_in 是从IMU的队列里取得的 也就是说IMU输入 即作为预测又作为观测吗 ？不像论文中提到的使用了随机过程。非常感谢！

Hi I installed the last version with conmmit [7701f1c] in two machines x86, worked good. I installed in two arm64 machines and in two different ways , modifying Point-lio to use Livox_ros_driver2:custom_msg and using the livox_ros_driver, in any case, with arm64 (jetson Orin NX 16gb) always crash in some point losing odometry and the map gets crazy jumping.

If you need I can help to test any change you make.

Could you please, at least make a different branch with the point-lio version previous to that commit?

Thanks.

为了表述清晰和节省时间，很抱歉直接使用中文。

前要：论文中提出对点云帧中每个点云分别按获取时间节点进行卡尔曼的更新，因此无需对整个点云包进行点云畸变处理。

但代码中的实现我认为可能存在问题，如果是我理解有误请指正：

h_model_input 函数中for (int j = 0; j < time_seq[k]; j++){...}的代码逻辑为：
从每个点云帧中按点云时间顺序抽取点云进行world近邻搜寻，但其中有一些问题:
t1: 针对点云第一个点进行最近邻搜索后，更新状态信息。
t2: 针对点云第一个点和第二个点进行最近邻搜索，更新状态信息。
...
tn：针对点云包中第一个点至第n个点进行最近邻搜索，更新状态信息。
但是，在每次状态更新时，如tn时间点，第1个点至第n-1个点都是直接用当前状态进行的body坐标系到world坐标系的变换，这实际上引入了点云畸变。

而在逻辑上，在tn时刻中，第一个点至第n-1个点在世界坐标系中的位置理应已经固定。
因此，我认为代码逻辑应该改为：在每一个时刻更新后，即刻固定所处理点云在世界坐标系中的位置。

Hi @Joanna-HE , I can't wait to see your accepted paper，your work in the video really impresses me deeply. I have a question about the meaning of "High-Bandwidth".

我按照Readme中的important notes，将imu_en置为fasle，设置gravity_init为[0.0, 0.0, -9.810]，以及use_imu_as_input置为0。
同时我还参考了#34，将gravity_align置为false以及start_in_aggressive_motion置为true，但是仍然没有效果，以下是我不使用imu的建图效果以及参数配置。

请问如果我想只使用激光雷达数据进行建图，该如何调整参数呢

@Joanna-HE
Hi, Thanks for your great work!
I've made a PR that adds a function to store the trajectory function at #5.

I can't hear any comments on this PR, so I'm opening an issue.
I would be happy to merge the PR if it would help. 😄

If there are any additional tests that need to be done or guidelines that need to be followed in order for the PR to merge, I'll do it.

I'd be grateful for your response.

Thanks,

Dear developer

Today you deleted the YouTube video about Point-LIO

Does this means that the project will not be public released or it means that there will be a new video because the paper was accepted and the code will be available?

Hoping the best

Thanks in advance

I tested point-lio with hesai's pandar128 lidar. found the Z drift is a llitte large.
and the config paramers as below, any suggestion for the config? Thanks very much.

common:
lid_topic: "/mi/lidar" # /mi/lidar /mi/lidar_at128
imu_topic: "/mi/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: 5
scan_line: 128
timestamp_unit: 2 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond.
blind: 4.0

mapping:
imu_en: true
start_in_aggressive_motion: false # if true, a preknown gravity should be provided in following gravity_init
extrinsic_est_en: false # for aggressive motion, set this variable false
imu_time_inte: 0.01 # = 1 / frequency of IMU
satu_acc: 30.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: 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.005 # 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 # 2
imu_meas_omg_cov: 0.1 #0.1 # 2
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.1, the threshold for plane criteria, the smaller, the flatter a plane
match_s: 81
fov_degree: 360
det_range: 100.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.00484558, 1.46794, 1.05397] # bhd048 lidar2imu
# extrinsic_R: [-0.999991, 0.000281534, 0.00420997,
# -0.000286678, -0.999999, -0.0012214,
# 0.00420962, -0.0012226, 0.99999]
# extrinsic_T: [ -0.0124961, 1.46534, 1.07669] # bhd033 lidar2imu
# extrinsic_R: [-0.999896, 0.00943061, -0.0109008,
# -0.00940029, -0.999952, -0.00282978,
# -0.010927, -0.00272701, 0.999937]
extrinsic_T: [ 0.0111163, 1.45795, 1.08458] # bhd027 lidar2imu
extrinsic_R: [-0.999945, 0.00930617, 0.00493594,
-0.00933933, -0.999934, -0.00673775,
0.00487291, -0.00678348, 0.999965]

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: true
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.
save_dir: "./PCD/"

filter_size_surf: 0.5

traj.txt
thereshould be no drift for the height z value, but the result is 4.6m

我在自己电脑上跑onedrive里面的数据集，分别使用
roslaunch point_lio mapping_avia.launch和
roslaunch point_lio mapping_horizon.launch
对四个数据集（PULSAR.bag pendulum.bag racing_drone.bag 'spinning_platform (1).bag'）进行测试，
但是总是有比较明显的偏移（一般是前期比较稳，后面会飘），是相关参数设置不对吗？

作者的工作很出色，我在测试中出现了这样的问题
throw "Error: Father ptr incompatible with current node\n";
在 ikd_tree.cpp 中有这样的异常抛出，想问一下在什么情况下会报这个异常，以及怎么解决。

建图过程中，像移动的行人、车子有去除效果吗？只保留静态地图

作者你好，非常感谢能分享这么棒的工作！但我在实际测试的时候发现了一些问题，use_imu_as_input设置成true比设置成false效果更好，这是否不太合理呢？这是我的测试数据集：https://1drv.ms/u/s!AjkIEg1kWUNeiAvyTCBBnR-jxLE1?e=jXvtla（使用的传感器是Livox MID-360，并且是倒置安装的）
以下是我设置的参数：

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
    start_in_aggressive_motion: false # if true, a preknown gravity should be provided in following gravity_init
    extrinsic_est_en: false # for aggressive motion, set this variable false
    imu_time_inte: 0.005 # = 1 / frequency of IMU
    satu_acc: 3.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.001 # 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: 100.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.806] # [0.0, 9.810, 0.0] # gravity to be aligned
    gravity_init: [0.0, 0.0, -9.806] # [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
    I_t_B: [ 0.0, 0.0, -0.2 ]
    I_R_B: [ 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.

期待回复，祝好～

i wanted to test point-lio on kitti rosbag generated by lio-sam script kitti2bag https://github.com/TixiaoShan/LIO-SAM/blob/master/config/doc/kitti2bag/kitti2bag.py
but i can t continue the process it stuck after run the launch file and do rosbag play it show some points on rviz but nothing more no save and no prints has been showed on the terminal
is there steps to do it ?

如图所示，下面两个位置符号(正负号)并不完全一致，可以解释下为什么这种形式么？ 十分感谢

in point_lio ,fast-lio ,gvins packages demand time async. so can you recomend some cheap time async method or equipments?

Thanks for sharing your great work! It's very intersting.
I have questions about the code implementation in laserMapping.cpp. Why separate state prediction from covariance prediction during IMU forward propagation? And, under what circumstances will dt_cov <= 0.0.

When I launch the point-lio, I echo the "/Laser_map", but it showed "has no new message" . How should I publish the topic in Point-lio? Thanks for your attention.

感谢作者开源的该算法，你好/aft_mapped_to_init话题输出频率大约为10hz，请问如何将其发布频率设置为固定100或200Hz,谢谢

我对use_imu_as_input不是很理解，这个应该是对应的point-lio与point-lio-input吧？分别对应kf-input与kf-output，但是为什么kf-input没有了加速度和角速度呢？

尊敬的作者，您好
首先十分感谢您开源了这么棒的工作！！其次我们也看到了代码中有hesai雷达的相关配置，但是我们在运行自己的数据集过程中，aft_mapped_to_init话题输出频率只有10HZ，是我们需要修改什么相关配置吗，以下是我们的配置参数，如果作者有相应的指教，将感激不尽！！
common:
lid_topic: "/hesai/pandar"
imu_topic: "/imu/data"
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: 4
scan_line: 16
timestamp_unit: 2 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond.
blind: 2.0

mapping:
imu_en: true
extrinsic_est_en: false # for aggressive motion, set this variable false
imu_time_inte: 0.01 # = 1 / frequency of IMU
satu_acc: 30.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: 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
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 # 2
imu_meas_omg_cov: 0.1 #0.1 # 2
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: 100.0
gravity: [0.0, 0.0, -9.810] # [-0.30, 0.880, -9.76] # liosam [0.0, 9.810, 0.0] # # preknown gravity, use when imu_en is false or start from a non-stationary state
extrinsic_T: [ 0, 0, 0.28] # ulhk # [-0.5, 1.4, 1.5] # utbm
# extrinsic_R: [ 0, 1, 0,
# -1, 0, 0,
# 0, 0, 1 ] # ulhk 5 6
# extrinsic_R: [ 0, -1, 0,
# 1, 0, 0,
# 0, 0, 1 ] # utbm 1, 2
extrinsic_R: [ 0, 1, 0,
-1, 0, 0,
0, 0, 1 ] # ulhk 4 utbm 3

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.

Hi @Joanna-HE, thanks for your excellent work!

I wonder if Example-1 and Example-2 datasets are publicly available?

Hi, thanks by share this nice and impressive package, do you know if it is possible use Livox Mid-360?

Cheers

Hello author, this is a great job. I have tested the relevant code, and I checked the topic /aft_mapped_to_init，and it is still only 10Hz. Is there something I have not set correctly?

真的非常不错的工作！

调试的时候发现velodyne luanch文件运行不了
readme 中的roslaunch point_lio mapping_velodyne.launch 中launch文件名写错了

hi, I have point-lio odometry working without any fine tunning, but it looks working very good.
My problem is I cannot get a dense pointcloud as only registered cloud is being published.

thanks

I've been running your algorithm using the ouster lidar (OS0-32) and it seems that PointLIO performs worse than FastLIO for trajectory estimation in certain cases.

It doesn't seem to work robustly, especially in narrow scenes (stairs, hallways, etc...).

<--- Result of Fast-LIO --->

<--- Result of Point-LIO --->

Below is the parameters i tested. (I used the same parameters when i tested Fast-LIO)

Can you please confirm what the problem is?

Thank you :)

common:
    lid_topic:  "/os_cloud_node/points"
    imu_topic:  "/os_cloud_node/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: 3 # 2 #velodyne                # 1 Livox Avia LiDAR
    scan_line: 32 # 32 #velodyne 6 avia
    timestamp_unit: 3           # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond.
    blind: 0.2

mapping:
    imu_en: true
    extrinsic_est_en: false # for aggressive motion, set this variable false
    imu_time_inte: 0.01 # = 1 / frequency of IMU
    satu_acc: 30.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: 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.1 # 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 # 2
    imu_meas_omg_cov: 0.1 #0.1 # 2 
    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: false # 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.0, 0.0, 0.0]
    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.

It seems in this paper:
PSD – probabilistic algorithm for mobile robot 6D localization without natural and artificial landmarks based on 2.5D map and a new type of laser scanner in GPS-denied scenarios
(https://doi.org/10.1016/j.mechatronics.2019.102308 )
The update process is also point-wise, but the implementation in Point-LIO looks more elegant! Great work!

hi , I'm using ros driver 2 and where before the bags worked good, now the bags from point-lio or from fast-lio fails as the odometry gets crazy, like when the imu is bad integrated or out synchro.
In real time it looks works good, just detected the issue in the bags.
Same bags with ring field in the topinc of the point cloud , as velodyne, will work.
Just for your info, for me it is not a problem as I can use ring information and will work or use the main branch, but this info maybe help you to improve.

cheers!

设置gravity 和 gravity_init 重力加速度都是9.81算法会飞。

I use imu of pixhawk 6C, Ouster lidar 16 mounted upside down. so i change the extrinsic_R of Z to visualize with +Z in rviz. But my Odometry data seem odd. Can you please take a look at it for me. common:
lid_topic: "/ouster/points"
#imu_topic: "/ouster/imu"
#imu_topic: "/imu_data"
imu_topic: "/mavros/imu/data_raw"
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: 1684841499.635005 #1684841493.84092665 #1684841499.635005 #1684841524.65910959 #1684841499.635005 #1694165984.83338928 #1694168642.17952871 #0.006376 #-0.48057733 #1684841524.65910959 # 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: 3 # 1 Livox Avia LiDAR
scan_line: 16 # 32 #velodyne 6 avia
timestamp_unit: 3 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond.
blind: 4

mapping:
imu_en: true
start_in_aggressive_motion: false # if true, a preknown gravity should be provided in following gravity_init
extrinsic_est_en: false # for aggressive motion, set this variable false
imu_time_inte: 0.02 # = 1 / frequency of IMU
satu_acc: 30 #80.0 # the saturation value of IMU's acceleration. not related to the units
satu_gyro: 25 # 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.01
acc_cov_output: 1000
gyr_cov_output: 2000
b_acc_cov: 0.07
b_gyr_cov: 0.3
imu_meas_acc_cov: 0.1 #0.1 # 2
imu_meas_omg_cov: 0.1 #0.1 # 2
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: 300.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] #[3.580628, 0.025035, -9.133134] # [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.0, 0.0, 0.0] #[-0.160931, 0.337930, -0.054396] #[-0.277508, -0.179171, -0.014018] #[0.0, 0.0, 0.0]ssss
extrinsic_R: [1, 0, 0,
0, -1, 0,
0, 0, -1 ]
#[ 0.033039, -0.822540, 0.567746,
#-0.987192, -0.115566, -0.109983,
#0.156078 , -0.556841, -0.815824 ]

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: true
interval: -1 # how many LiDAR frames saved in each pcd file;

首先非常感谢您的开源,我在适配补盲激光雷达的时候发现一个问题,使用output模式，感觉收敛的很慢，导致累积偏移很大，导致建图漂移，如下图表现

我的配置文件如下，需要再从哪些方向调整参数。非常感谢
common:
lid_topic: "/raw_points"
imu_topic: "/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: 5
scan_line: 32
timestamp_unit: 2 # the unit of time/t field in the PointCloud2 rostopic: 0-second, 1-milisecond, 2-microsecond, 3-nanosecond.
blind: 2.0

mapping:
imu_en: true
extrinsic_est_en: false # for aggressive motion, set this variable false
imu_time_inte: 0.01 # = 1 / frequency of IMU
satu_acc: 30.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: 9.80 # 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
acc_cov_output: 500
gyr_cov_output: 500
b_acc_cov: 0.01
b_gyr_cov: 0.001
imu_meas_acc_cov: 0.2 #0.1 # 2
imu_meas_omg_cov: 0.2 #0.1 # 2
gyr_cov_input: 0.001 # 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: 120
det_range: 100.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.80] # [0.0, 9.810, 0.0] # gravity to be aligned
gravity_init: [0.0, 0.0, -9.80] # [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, 0.0, 0.06]
extrinsic_R: [ 0, -1, 0,
1, 0, 0,
0, 0, 1 ] # ulhk 4 utbm
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.

作者你好，我测试了您的算法在 Velodyne 和 Ouster 数据上效果很好，但是在livox激光上运行时出现了下面的问题。我尝试了很多方法，但是没有找到解决办法，你可以给我提供一些建议？

感谢作者开源的该算法，在aft_mapped_to_init话题输出频率只有10hz，设置为ture时可达到几千Hz,想请教以下如何将其发布频率设置为100或200Hz,需要修改哪里？期待您的回答！谢谢