Is my unit defective or software issue?

[kawogi]

I just purchased an L2 and tried to get it up and running.

When plugging in the LIDAR for the first time the dome started rotating (roughly 5 Hz which seems ok) and after a couple of seconds the mirror started up spinning very fast and rather noisy. While the rotation speed seemed but I don't know about the loudness.

I then managed to connect via the SDK example_lidar_udp (current main branch successfully built on a Linux Mint) and got some output:

[UDPHandler] create udp socket success.
[UDPHandler] bind udp port success. port 6201.
[UDPHandler] set udp recv timeout success. 1 sec.
Unilidar initialization succeed!
set Lidar work mode to: 0
lidar hardware version = 2.2.1.1
lidar firmware version = 2.6.6.1
lidar sdk version = 2.0.9
stop lidar rotation ...
start lidar rotation ...

The LIDAR stops and starts the dome's rotation according to the program's progress and I can ping the unit. The green led seems to be blinking at 1 Hz but it not synchronized to the dome's rotation.

Then … nothing happens. According to the docs the dirty percentage should be measured and printed, but the program just hangs there forever (at least 20 minutes) before I cancelled it.

I then removed the percentage measurement to see whether the next steps would succeed and indeed:

(same as previous)
…
dirty percentage = 0.000000 %
time delay (second) = 0.007439
An IMU msg is parsed!
        system stamp = 1767579601.2101900578
        seq = 621, stamp = 1767579601.210131168
        quaternion (x, y, z, w) = [0.9980, -0.0165, -0.0047, -0.0154]
        angular_velocity (x, y, z) = [-0.0158, 0.0125, -0.0029]
        linear_acceleration (x, y, z) = [0.0665, -0.1263, 9.7224]
An IMU msg is parsed!
        system stamp = 1767579601.2102320194
        seq = 622, stamp = 1767579601.210229396
        quaternion (x, y, z, w) = [0.9980, -0.0165, -0.0047, -0.0154]
        angular_velocity (x, y, z) = [-0.0165, 0.0097, -0.0010]
        linear_acceleration (x, y, z) = [0.0777, -0.0891, 9.7374]
…

I'm being flooded with (meaningful?) IMU data but no point cloud. The unit's base is getting very hot - so much that it's painful to hold in my hand. Also the spinning dome seems inbalanced - you cannot hold it still in your hand which will make it hard to get good measures without mounting it onto heavy equipment.

I also noticed the the mirror seems to not be spinning any more. Through a phone camera I can see occasional laser flashes in various locations but it's hard to tell whether anything meaningful is happening.
I tried switching to serial and swapped the power supply, but the result is the same.

My questions is whether my unit might be defective. Is the above behavior expected/fixable? Is there any secret switch to spin up the mirrors?

I do not expect any response from unitree - given their record of not responding to any issues, but maybe someone else can help me with some insights. Thanks a lot in advance.

ps: I'm also not amused that their so-called open-source-SDK is just header files. Makes it unnecessarily hard to use and debug their product.

[markgol]

I have been working with the unit for about 1-1/2 weeks. I will post a far more detailed response shortly.

[markgol]

I am not with Unitree. As near as I can tell Unitree has not responded to anything in this repository since March 2025. I was aware of several of the problems before I purchased the L2. I have in the past been able to reverse engineer comm interfaces but it takes a little time. The documentation is severely lacking. I have observed the same problems as others including your issues. I can provide you with what I have done so far and maybe collaboratively move forward with this. I do plan to fork this to my github repository and provide updates as I work through what I find.
1.) The Windows program they provide on their website, https://www.unitree.com/download/L2, labelled Unilidar Point Cloud Software appears to have a crypto mining malware embedded. This is verified by ESET antivirus when trying to download. I have not used it nor plan to use it.
2.) Initial power up L2 vibration. If you unit is not bolted to a solid platform you should place is on a solid surface on the soft rubber pad Unitree included the kit. The vibration is caused by the gyroscopic motion generated once both motors are running. You can equate this to trying to hold a spinning bicycle wheel and turning. This can not be avoided with the design they used. I have my unit placed on the soft rubber piece they provided on top of a 30cm x 30cm x 2cm thick aluminum plate which sits on a bubble wrap layer on a table. This significantly reduced the noise but did not eliminate it.
3.) operation at start up or using the example programs. The default operation at power on is to be in 3d scanning and IMU enabled. It talkes about 10 to 15 seconds to fully spin up. Some of the sleep() commands in example_lidar_udp are not long enough. I made a VS code project which can build all of the example apps and allow you to debug step through the applications. I will post on a project fork toward the end of this week.
4.) IMU data. The IMU data you posted looks normal.
5.) Overheating. I have not had a problem with it overheating. It gets warm but not to the point that one can not touch it. One of the important things is not to plug the power supply into the USB/serial board. While it is the same plug it is not the same voltage.
6.) Try disconnecting everything and then plugging in just the power. If it is in the default factory settings it should spin up. It should start spinning the horizontal motor after 1 second then after about 10-12 seconds it should start the scan mirror motor.
None of the example program look like they are capable of changing the startup mode unless you use some other calls in the SDK library. If the motors do not start then something is likely wrong with the unit.
Lastly, the documentation for the SDK is severely lacking. I have been building an L2 diagnostic program in Qt Creator just using unitree_lidar_protocols.h and unitree_lidar_utilities.h include file so I am not relying quirkiness of non-open source unitree libunilidar_sdk2.a library. I will also be posting that project in my github repository. I have can receive IMU and PCL packets with correct data or no packet loss. Packet rate is approx. ~520 packet/sec on ethernet. Slightly higher percentage being IMU packets rather that PCL packets. I have seen an issue with the using the crc32 function they provided generating matching received packet CRCs base on the descriptions in the header files. I will post that as a separate issue.

[kawogi]

Thanks a lot for your feedback - very appreciated.

As a matter of fact, the LIDAR did spin up later that day after reconnecting everything (and maybe cooling down) and everything looks fine now. Let's see how this works out in the long run.

The Windows program they provide on their website, https://www.unitree.com/download/L2, labelled Unilidar Point Cloud Software appears to have a crypto mining malware embedded.

This is a severe accusation and I'd be very cautious about that. I just let have VirusTotal a look and I'd call the results suspicious: https://www.virustotal.com/gui/file/2aaa6d5d6226de97506199bcd0d7b7a85e846b314fead84e46e55c49f551ae24 - remember that every result with gen…, sus… or heur… in it is just some wild guess. I've had my own software being flagged dozens of times for no reason. Randomly changing the embedded icons helped 🙄. I'd still be cautious and since I don't have Windows I'll need a better solution anyway.

I was planning to write an open source library to cover the communication with the device. So yes, maybe we can join forces - at least in reverse-engineering the protocol. The library will be written in Rust.

My next step would be to capture a working communication and try to decode that.

I have seen an issue with the using the crc32 function they provided generating matching received packet CRCs base on the descriptions in the header files.

I think I might have read that the protocol uses CRC16, but I didn't dive deeper, yet, because the device didn't work at all.

[markgol]

The file unitree_lidar_utilities.h contains a crc32 algorithm. The crc field in the packet tail is 32 bits. I started by using Wireshark to initially capture packets and compare them to the structures defined in unitree_lidar_protocols.h. To isolate packets being sent
to the L2 the display filter: ip.dst == 192.168.1.62 && tcp.port == 6101 is useful.

[kawogi]

Ha, you're ahead of me :)

Just captured the packets using Wireshark (directly connected to ETH so no filter needed). If everything goes smooth, I'll create a repo soon and let you know - so that we can have a better place to talk. I'll focus on UDP for now, but adapting to serial should be simple enough.

related to my original question: the mirror now reliably spins up and works as intended. I'll keep it running for a while to see whether it overheats again.

[markgol]

I found that only IMU and PCL packets are being sent by the L2 unless you send out packets out to the L2 such as a user cmd packet or cmd packet. I have not looked at the serial interface since it doesn't appear to be fast enough to operate at full rate. In my application I was not planning on using the serial interface only the UDP ethernet as a peer to peer connection.

[markgol]

I have created a Discord server for a L2 community discord. If you want to join use the following link:
https://discord.gg/2QYuXwutjG
This may be easier way to communicate, share and collaborate technical information about the L2.