Persistent lidar loop back, clear buffer with Unitree 4D LiDAR L2 (Non-Repetitive Scanning)

I am attempting to run Point-LIO using the Unitree 4D LiDAR L2 (lidar_type 5) and its built-in IMU. Despite tuning critical time synchronization and non-repetitive scanning parameters, the laserMapping node successfully initializes the IMU (100%) but immediately begins logging the lidar loop back, clear buffer error continuously, causing the system to fail to start mapping. please see the detail as below. Hopefully anyone can help me to fix this issue.

This suggests either an unaddressed time/buffer overflow issue or a computational bottleneck in the feature extraction/optimization steps when handling the L2's non-repetitive point cloud segments.
Component Detail
LiDAR Model Unitree 4D LiDAR L2 (Non-Repetitive Scanning)
LiDAR Type lidar_type: 5
Software Point-LIO ROS2 (fork)
ROS Distribution ROS2 Humble
LiDAR Topic /unilidar/cloud
IMU Topic /unilidar/imu

The IMU initialization succeeds, but the lidar loop back starts shortly after:

[pointlio_mapping-1] [INFO] [1760190128.684111145] [laserMapping]: IMU Initializing: 100.0 %
[pointlio_mapping-1] [ERROR] [1760190146.843403073] [laserMapping]: lidar loop back, clear buffer
[pointlio_mapping-1] [ERROR] [1760190146.977735448] [laserMapping]: lidar loop back, clear buffer
[pointlio_mapping-1] [ERROR] [1760190147.114740286] [laserMapping]: lidar loop back, clear buffer
... (error repeats continuously)

ros__parameters:
common:
# CRITICAL: Non-repetitive Lidar segmentation and synchronization
cut_frame: true
cut_frame_time_interval: 0.05
time_lag_imu_to_lidar: 0.01

preprocess:
    lidar_type: 5
    timestamp_unit: 2           # Microsecond resolution (CRITICAL for LIO)

mapping:
    imu_en: true
    imu_time_inte: 0.002        # Matched to high-frequency IMU
    
    # Aggressive Downsampling to mitigate computational bottleneck (Recommended next step)
    filter_size_surf: 0.5       
    filter_size_map: 0.5  

[rsmsvm]

Hi, I have a similar issue for IMU:

[pointlio_mapping-1] [ERROR] [1767882693.029092738] [laserMapping]: imu loop back, clear deque

[pointlio_mapping-1] [ERROR] [1767882693.029711315] [laserMapping]: imu loop back, clear deque

[pointlio_mapping-1] [ERROR] [1767882693.038194893] [laserMapping]: imu loop back, clear deque

[pointlio_mapping-1] [ERROR] [1767882693.040243782] [laserMapping]: imu loop back, clear deque

[pointlio_mapping-1] [ERROR] [1767882693.051793116] [laserMapping]: imu loop back, clear deque

Is that familiar to you? Do you have a solution or opinion for this problem?

[Charlescai123]

I encountered the same issue. The root cause is related to the timestamps published by the Unitree Go2 internal board.

This repository assumes that incoming sensor data must have monotonically increasing timestamps. If a new message has a timestamp earlier than the previous one, it will be dropped.

If you check the topics provided by Unitree, for example:

• LiDAR topic: /utlidar/cloud

• IMU topic: /utlidar/imu)

You will notice that the timestamps are fixed around a specific date. You can verify this using a command like:

ros2 topic echo --once /utlidar/imu --field header.stamp.sec | head -n1 | xargs -I{} date -d @{}

On my machine it shows something like:

Wed Sep 24 xx:xx:xx AM EDT 2025

You will likely see a similar result. This means the timestamps published by the robot are around September 2025.

Because of the synchronization rule in the code, your system time must be later than this timestamp, otherwise the incoming IMU/LiDAR data may be rejected or never processed.

That is why the problem is often solved automatically once the system time is synchronized through the network (e.g., via NTP). You can also fix it manually by setting your system time to a later date using the date command.

This issue commonly happens on edge devices such as NVIDIA Jetson, because they typically reset the system clock to 1970 after reboot if there is no RTC battery. The time only gets corrected once the device connects to the network.

Hello my friend I just got my email back. Thank you for this information. But have you done fixed this issue yet ? One more thing it seems likes I can create the correct points the longest is around 2mn after 2mn everything turned out completely wrong. Data misaligned, spiky clouds, tf jump. Thank Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Pika ***@***.***> Sent: Saturday, March 14, 2026 11:32:34 AM To: hku-mars/Point-LIO ***@***.***> Cc: MAO Phearun ***@***.***>; Author ***@***.***> Subject: Re: [hku-mars/Point-LIO] Persistent lidar loop back, clear buffer with Unitree 4D LiDAR L2 (Non-Repetitive Scanning) (Issue #121) [https://avatars.githubusercontent.com/u/31382132?s=20&v=4]Charlescai123 left a comment (hku-mars/Point-LIO#121)<#121 (comment)> I encountered the same issue. The root cause is related to the timestamps published by the Unitree Go2 internal board. This repository assumes that incoming sensor data must have monotonically increasing timestamps. If a new message has a timestamp earlier than the previous one, it will be dropped. If you check the topics provided by Unitree, for example: * LiDAR topic: /utlidar/cloud * IMU topic: /utlidar/imu) You will notice that the timestamps are fixed around a specific date. You can verify this using a command like: ros2 topic echo --once /utlidar/imu --field header.stamp.sec | head -n1 | xargs -I{} date -d @{} On my machine it shows something like: Wed Sep 24 xx:xx:xx AM EDT 2025 You will likely see a similar result. This means the timestamps published by the robot are around September 2025. Because of the synchronization rule in the code, your system time must be later than this timestamp, otherwise the incoming IMU/LiDAR data may be rejected or never processed. That is why the problem is often solved automatically once the system time is synchronized through the network (e.g., via NTP). You can also fix it manually by setting your system time to a later date using the date command. This issue commonly happens on edge devices such as NVIDIA Jetson, because they typically reset the system clock to 1970 after reboot if there is no RTC battery. The time only gets corrected once the device connects to the network. — Reply to this email directly, view it on GitHub<#121 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BPYO6WQSO5SVFER4SXKFCOD4QTOGBAVCNFSM6AAAAACI5I4YIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJZGUYDINRVHE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Charlescai123]

Hello my friend I just got my email back. Thank you for this information. But have you done fixed this issue yet ? One more thing it seems likes I can create the correct points the longest is around 2mn after 2mn everything turned out completely wrong. Data misaligned, spiky clouds, tf jump.
Thank

Get Outlook for Androidhttps://aka.ms/AAb9ysg
…

Hi, this could result from a time synchronization issue.

On my side, it was caused by timezone misalignment after the device lost internet connection, which led to incorrect system time. I fixed it by adding an RTC battery so the system clock stays correct even when offline.

Your symptom — working fine for ~2 minutes and then breaking (misalignment, spiky clouds, TF jumps) may suggest your system time is drifting or inconsistent across nodes.

I believe you could check:

1. system time after startup
2. whether all nodes/sensors use consistent timestamps

If your device runs offline, you’ll likely need an RTC battery as well.