['time' field in LiDAR data] Time offset is with respect to the end of the rotation

[qpc001]

When I start to play the bag, LIMO-Velo run a few scan (n<5), then stuck.

[Huguet57]

Does e6bebf5b87a8869d683bc0a921fa49f455ea2c1a work?

[qpc001]

Does e6bebf5 work?

no, but [db67b8e285e13882a89d8ad78437f7678e12e30e] work well.

[Huguet57]

Does it happen with xaloc.launch?

[qpc001]

Does it happen with xaloc.launch?

I run test.launch with my own dataset.

[Huguet57]

:warning: I just found that e6bebf5b87a8869d683bc0a921fa49f455ea2c1a has a bug. fill_config() needs nh as argument. Try a later commit

[Huguet57]

However, I just tried it and it doesn't compile... Does your error happen in latter commits?

[qpc001]

However, I just tried it and it doesn't compile... Does your error happen in latter commits?

yes, I can upload my dataset if you need.

[Huguet57]

Interesting. It seems that is a time management related error. If you could upload your dataset that would be great!

[Huguet57]

Does your LiDAR scan have "time" data?

[Huguet57]

Actually I think I might just found the error, try to comment "heuristic" part in the YAML file and uncomment the "without heuristic"

[qpc001]

That make it work, is there a bug ?

[Huguet57]

Your LiDAR must go @ 10Hz and if t2-t1 is less than 0.1 seconds then it doesn't find points with timestamps between t1 and t2

[qpc001]

yes, I use vlp-16

[Huguet57]

Mm this is really interesting, a modern Velodyne ROS driver should output 'time' value in the points. Could you upload a couple of seconds of data to see what's happening?

[Huguet57]

This post is related to this problem.

Does your /velodyne_points look like this in RViz when you put Channel Transform = "Intensity" and Channel Time = time? It should look like a rainbow, just like this image.

[Huguet57]

If it does, then it would really be interesting to get to look at the data. That means this part: https://github.com/Huguet57/LIMO-Velo/blob/13a4d3fb33b83131995a976987d3dec923db077a/include/Headers/Common.hpp#L160-L167

Is not the same for your VLP-16. Xaloc uses a fairly old (~4 years) VLP-32C.

[qpc001]

I just sent you a 15s ros bag to your email.

An interesting things is , my velodyne point cloud time stamp is the end of the scan.

Here is my param file.

mapping_online: true # set to 'true' until mapping offline fixed (see Discussions in GitHub) real_time: false # in a slow CPU, real_time ensures to always output to latest odometry (possibly skipping points)

estimate_extrinsics: false print_extrinsics: false initial_gravity: [0.0, 0.0, 9.807]

I_Translation_L: [0.0, 0.0, 0.0] I_Rotation_L: [ 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0 ]

empty_lidar_time: 0.1 # Should be at least [FULL_ROTATION_TIME] real_time_delay: 0.1 # Should be at least [FULL_ROTATION_TIME] (without a modificated LiDAR driver)

LiDAR_type: velodyne # Options: velodyne, hesai, ouster, custom LiDAR_noise: 0.001 full_rotation_time: 0.1 min_dist: 0.5 # Minimum distance: doesn't use points closer than this radius ds_rate: 1 # Downsampling rate: results show that this one can be up to 32 and still work, try it if you need a speedup

imu_rate: 500 # Approximated IMU rate: only used to estimate when to start the algorithm covariance_acceleration: 1.e-1 covariance_gyroscope: 1.e-2 covariance_bias_acceleration: 1.e-2 covariance_bias_gyroscope: 1.e-3

MAX_NUM_ITERS: 5 NUM_MATCH_POINTS: 5 MAX_DIST_PLANE: 2.0 PLANES_THRESHOLD: 5.e-2

degeneracy_threshold: 5. # Its magnitude depends on delta (see below), keeping it too high can cause blurry results print_degeneracy_values: false # Print the degeneracy eigenvalues to guess what the threshold must be for you

Heuristic: times: [0.5, 1.0] deltas: [0.1, 0.05, 0.02]

[Huguet57]

An interesting things is , my velodyne point cloud time stamp is the end of the scan.

This is usually the case for Velodyne LiDARs, and not having 'time' data is dangerous since then you will always go 0.1 seconds desynchronized with the IMU. LIMO-Velo assumes there's time data in each point and this goes from 0 (earliest point) to 0.1 (latest point). Hence the time of beginning without time is badly calculated here:

https://github.com/Huguet57/LIMO-Velo/blob/c70c311ef05d9f046debd1b00f42fc89977f3a99/src/Utils/PointCloudProcessor.cpp#L42-L45

And it is indeed the "finish" time.

I will have a look at the data you sent me, thank you!

[Huguet57]

This is really interesting, your data does have time data (I hope you don't mind showing the screenshot) but it goes from -0.1 to 0 (actually, it makes way more sense that way). This calls for a urgent fix, I will get onto it.

[Huguet57]

@qpc001 replacing this line: https://github.com/Huguet57/LIMO-Velo/blob/c70c311ef05d9f046debd1b00f42fc89977f3a99/src/Utils/PointCloudProcessor.cpp#L44 For: return Conversions::microsec2Sec(pcl.header.stamp);

Already improves a lot your case. I am going to find a way to detect automatically or at least choose in the YAML the 'time' field format. Also, I had no problem using the Heuristic.

[Huguet57]

@qpc001 issue fixed, in your VLP-16 case, the new parameters should be:

https://github.com/Huguet57/LIMO-Velo/blob/f5ab92ed0bb1f54f0ad581e25b9cd06b1666c11c/config/params.yaml#L25-L28

As updated in the params.yaml file.