Unitree Lidar L1
sensor for small and slow robots
Do you want your robot to not bump into obstacles or fall into holes, are not happy with the limitations of stereo vision, but you are not willing to pay for an Ouster (resp. Velodyne)/RoboSense/Livox/… "industrial" 3D lidar? Worry no more, there is a new player on the scene. Blog update: 12/6/2024 — Two out of three
Unitree Lidar L1 - The Hardware
Unitree, a producer of quadruped and humanoid robots, now also offers a budget-friendlier lidar.
In their own words: "360° × 90° Omnidirectional ultra-wide angle scanning; Replacing traditional LIDAR sensing solution, achieving the same effect, with less than 1/10 of the price." They offer it for $349 on their shop, which happens to be exactly what Luxonis asks for OAK-D Pro stereo camera.
The argument by Unitree is that for small and slow robots, one does not need a "full" 3D lidar.
Unitree L1 is relatively slow and sparse and its design reminds me a lot of RPLidar. There is a rotating head over a single "normal" TOF sensor and that's it. Except that L1's head rotates around two axes, unlike RPLidar's one axis.
From all that you can deduce that the capabilities of this sensor are expected to sit somewhere between RPLidar and the "industrial" 3D lidars. And indeed they do: L1 provides 21600 measurements per second, which is not that many, and measures distances between 0.05 and 20 meters, which is fine, at 11 Hz, which is OK. Resp. this is for the PM "precision" model. There is also a 30m "long range" RM version, which costs more. I did not find other differences between their specifications.
Unitree advertisers "non-repetitive static scanning" as a feature. Two consecutive scans from a static lidar will measure different parts of the environment. Well, the rotations around the two axes are simply not synchronized, as far as I can tell, so the lidar measures wherever it happens to point at the moment. Wherever it points is probably estimated from some encoders or from some rotation key(s) and time interpolation. This hardware goes as simple as it gets. Do not expect any nicely aligned lines in the produced data.
There is also an onboard IMU on the device.
It wasn't very clear to me what is in the box, so here we go:
- The sensor itself.
- 53cm dangling UART + Power connector. It is mechanically mounted to the lidar, which I find very unfortunate, because it makes it harder to replace it with a shorter one. Space is a luxurious item on a small robot and cables tend to eat it. There is a 4-pin GH1.25mm JST connector on the dangling end. This one is described in the documentation.
- The box contains a USB-to-UART converter based on CP2104. If you want to use your own, keep in mind that you are aiming for 2Mbaud. Not all converters support that. The JST connector plugs into this converter. CP2104 reports a serial number, which means it should be possible to connect multiple such lidars on a single robot and differentiate between them in the operating system.
- A 100-240VAC 12V/1A power adapter is supposed to provide energy. It is an American plug. Very useless to me. But the whole thing ends up on a mobile robot anyway, so what is the adapter for?
- Which brings us to an important part that is not documented or I missed it: The outer diameter of the power barrel going into the UART converter is 3.5mm. I am unfortunately uncertain about the inner diameter, because I happend to have an unlabeled connector that fits. I can put a 1.1mm nail into the connector, fwiw. On one hand, it fits in without falling out, on the other hand I can slightly wiggle it. 1.3mm inner diameter is not entirely out of question.
- There is a 1m USB-A to USB-C cable for connecting the UART converter with the computer.
- And there are few small screws for mounting the lidar.
Let's keep the software part and experience with it for later articles.
The Software
Unitree provides an SDK for communication with the lidar on Github. The project provides header files and static libraries. I … don't like binary libraries like this. I really don't. Have I mentioned I don't like binary libraries?
These ones are at least static, so there is less of a chance of some dependency of theirs disappearing after some time. Still, I am pretty confident that two or three years from now I would struggle making it work on some system or hardware. I already have MyntEye stereo cameras that I can use as cute bricks, because the company went bankrupt and their binary SDK stopped working over time. Even if Unitree does not go bankrupt, will they care about supporting this particular lidar three years from now?
The good news is that the SDK works for me (TM) now. Which means I can log communication to and from the lidar, cross-check with the pieces of code that are on Github and write my own communication library. I would not have bought the lidar without being confident I can do this. I was still over-confident and got lucky.
To reiterate before I get into details: The SDK works (for me). You can likely use it without getting as defensive as I am and writing an own library. If you want to make sure before buying the lidar, compile the SDK, create a linux pseudoterminal (pty) - I used `socat` to do the job for me - and let the example code in the SDK write to the pty. You will need to modify the example to not open /dev/ttyUSB0, but the pty. You should see the example writing some data into the pty and then complaining about timing out before receiving data from the lidar. Which is, given you have not bought it and plugged it in yet, a perfectly correct behavior.
The important pieces of information for defensive folks are:
- Unilidar L1 uses Mavlink v2 communication protocol without message signatures.
- The Github repository contains code for processing input and output messages generated by Mavgen. I could either use this code directly to parse and serialize the messages or there is enough information to understand the message structure and to peek magical parameters such as "extra checksum".
- Where I got lucky, or Unitree is friendlier than I am giving them credit, is that the repository also contains code for turning distance data packet and auxiliary data packet into a point cloud with reflexivity. This is non-trivial and I am not sure if I could deduce it from the structure of the two messages. Maybe. If I am optimistic. It would certainly take a lot of time.
With all this information … yes, I can parse the incoming data myself. Distance, reflexivity, IMU. At some point I should also send commands (turning the lidar on and off - it is on by default) and, with lower priority, to control LEDs.
Some of the messages I receive do not pass a checksum test. I may not be parsing data correctly, but I don't think this is the case. There isn't that much room for mistakes. Famous last words. Maybe there are some communication hiccups? Remember the half a meter long dangling serial line cable I mentioned in the previous article?
One more detail you may find interesting or important is that one distance + auxiliary data packet pair contains measurements from one rotation of the "fast" mirror. It is almost as getting 120 measurements from a 180deg field of view 2D lidar. Except that the slower axis of rotation gives it an extra twist, so the 2D scan does not come from a plane, even when the robot is static. And then you get another packet pair with another slice, slightly rotated. And then another one. And another one.
Vertical slice of my office room with L1 on a table, facing up:
 L1 scan |
Two out of three
I did not mention it before, but I got two L1 lidars, not just one. After I made my software work with the first one, I finally plugged in the second one. I should have done it earlier and try it with the provided software. Because the second one did not work.
Luckily I did it just before the expiration of the "no questions asked" return window of the European re-seller I bought them from. Mind you, I am not in EU and some of the EU customer protections are complicated here or do not apply at all.
I traced the issue to the USB-TTL converter. The sensor itself was OK. It worked with the converter from the first unit. Unitree - the original producer - does not provide spare parts. At least not this one. Despite its simplicity, I did not manage to make my own USB-TTL work with the lidar. I may have just been soldering the teeny-weeny GH JST connector wrong. Or there is more to the converter, such as a some magical wake-up byte exchange. I have not explored deeper. The provided USB-TTL converter is wrapped in a transparent piece of plastic and I could check it neither visually, nor with a multimeter or other measurement tool without breaking that plastic.
Either way, with the return window very quickly closing and the event where I need the robot to work approaching, I have returned the second lidar and bought a third one instead. Poor man's "give me a replacement." The third unit works fine, which gives me two units out of three working.