mirroring/drift present could be a config issue

[xzxzZzxzx]

so for the L1 Untiree LiDAR ,which i am slowly realizing is a terrible product due to its mechanical imbalance, this is what i usual run in sequence
Terminal 1 — Start Unitree driver (calibrates IMU)
cd ~/unitree_lidar_ws
source devel/setup.bash
roslaunch unitree_lidar_ros run_without_rviz.launch

Terminal 2 — Start FAST-LIO-SAM-QN
cd ~/fastlio_sam_qn_ws
source devel/setup.bash
roslaunch fast_lio_sam_qn run.launch

so really not so sure why this drifts into infinity my only guess is because i don't move and the Lidar is shaking even though i am holding it down

[xzxzZzxzx]

so close yet so far this is when i went to the garage of a building. its supposed to be one triangle like photo (no.2) it is top view at least it didn't drift in the vertical sense(z axis ) seems legit oh yes i did two laps only in one direction maybe i should've walked backward so it corrects better? idk

(no.1)

(no.2)

[xzxzZzxzx]

so far i changed the following:
extrinsic_T: [0, 0, 0]
extrinsic_R: [1, 0, 0,
0, 1, 0,
0, 0, 1]
reason being the Unitree L1 has its IMU built in super close. extrinsic_T was [0, 0, 0.28]
also i understand that a hallway or a garage might be too symmetric but each corner of this garage is unique in a sense.
btw this is the result doing only one lap struggles to connect the ends together. red arrows are the path i walked and i labeled some of the areas to avoid confusions on here it seems pretty accurate especially the flatness and dips in the ground for water drainage. it just gets confused when coming around the start finish area. i didn't want to do two laps to avoid the overlapping issue however i might need to in the future to increase resolution for certain features like the bicycle area top left of the map

if i reached a physical limitation of point LIO SLAM please let me know i will probably do tests outdoors to see if loop closure on the L1 Unitree LiDAR is possible

[xzxzZzxzx]

cleanest scan so far i started at a specific corner in the garage i changed the following parameters from mapping_velodyne.launch to : cube_side_length: 100 filter_size_map: 0.7 max_iteration: 2

[engcang]

@xzxzZzxzx Thank you for sharing your experience and interest on my works.
Unfortunately, I am not sure what your questions are. What do you want to ask me? What should I help you for?

So for the mapping results, yeah as you are figuring out yourself, the parameters and calibration of FAST-LIO itself should be modified properly.
This FAST-LIO-SAM-QN repository is more about loop-closing with Quatro and Nano-GICP, but not the odometry of FAST-LIO itself.
But, your problem seems all from FAST-LIO's odometry for now.

For the last image you attached, not it seems that the odometry is quite good enough.
Please try to use loop-closing with QN and then also share your experience with it.
I guess L1 LiDAR's scan is too sparse to close the loop with the current version of QN code. I guess you should stack a lot more scans and then try to close the loop.

[xzxzZzxzx]

The pleasure is all mine. your work was recommended in other repositories. Apologizes for not having a precise question or problem. But Yes I am more or less sharing my experience in hope for valuable feedback such as yours, which am very grateful for. Since i have only learned about POINT-LIO and FAST-LIO last week i am not as knowledgeable yet.

based on your feedback i did the following changes to fast_lio_sam_qn/config/config.yaml :
before (default) :

keyframe:
  keyframe_threshold: 1.5                     # unit [meter] every this distance, generate keyframe
  num_submap_keyframes: 10                     # how many subkeyframes are merged to ICP with current keyframe (closest-this ~ closest+this, if exists)
  enable_submap_matching: false               # If it is set to be true, submap-level (coarse-to-)fine alignment will be performed
                                              # note: without Quatro, anyway scan-to-submap matching is performed, as that shows better performance
loop:
  loop_detection_radius: 35.0                 # unit [meter] within this radius, check if loop or not
  loop_detection_timediff_threshold: 30.0     # unit [sec] check if two keyframes are loop if times are farther than this
quatro_nano_gicp_voxel_resolution: 0.3        # voxel resolution to use Quatro and Nano-GICP matching
save_voxel_resolution: 0.3                    # voxel resolution to save map in .pcd format

nano_gicp:                                    # all values are from Nano-GICP official github (Direct LiDAR Odometry)
icp_score_threshold: 1.5                    # lower is more accurate, for loop detection

quatro:                                       
fpfh_normal_radius: 0.9                     # It should be 2.5 - 3.0 * `quatro_nano_gicp_voxel_resolution`
  fpfh_radius: 1.5                            # It should be 5.0 * `quatro_nano_gicp_voxel_resolution`
noise_bound: 0.3                            # The magnitude of uncertainty of measurements, the best is within v/2 ~ v (v: voxel resol.)  

after:

keyframe:
  keyframe_threshold: 1                     # unit [meter] every this distance, generate keyframe
  num_submap_keyframes: 30                     # how many subkeyframes are merged to ICP with current keyframe (closest-this ~ closest+this, if exists)
  enable_submap_matching: true               # If it is set to be `true`, submap-level (coarse-to-)fine alignment will be performed
                                              # note: without Quatro, anyway scan-to-submap matching is performed, as that shows better performance
loop:
  loop_detection_radius: 35.0                 # unit [meter] within this radius, check if loop or not
  loop_detection_timediff_threshold: 60.0     # unit [sec] check if two keyframes are loop if times are farther than this

quatro_nano_gicp_voxel_resolution: 0.2        # voxel resolution to use Quatro and Nano-GICP matching
save_voxel_resolution: 0.2                    # voxel resolution to save map in .pcd format

nano_gicp:                                    # all values are from Nano-GICP official github (Direct LiDAR Odometry)
  icp_score_threshold: 1.1                    # lower is more accurate, for loop detection

quatro:                                                
  fpfh_normal_radius: 1.9                     # It should be 2.5 - 3.0 * `quatro_nano_gicp_voxel_resolution`
  fpfh_radius: 1.0                            # It should be 5.0 * `quatro_nano_gicp_voxel_resolution`
  noise_bound: 0.15                            # The magnitude of uncertainty of measurements, the best is within v/2 ~ v (v: voxel resol.)

i am still exploring your code so if i missed an important parameter feel free to guide me.
i will edit this comment with the new results as soon as i get the chance

came out a little worse so i will change back the settings and tune them one by one