Getting an LD06 Lidar onto the MediaTek Genio

A lidar that shows up on the USB bus but never becomes a serial port is a classic embedded dead end. Our LD06 lidar did exactly that on the MediaTek Genio’s vendor kernel, and getting it working meant either adding a driver to a kernel we could not easily rebuild, or bypassing USB entirely. Here is the situation and both routes out.

Key Insights

• The LD06 uses a CH340-class USB-serial chip that needs the ch341 driver, which the vendor kernel did not include
• Without the driver the lidar enumerated on USB but never got a serial device node, so the software found nothing to open
• The fix was to build the driver as an out-of-tree kernel module against the vendor kernel, which has a real gotcha around build options
• The alternative is to wire the lidar to a hardware UART on the carrier and skip USB, at the cost of a possible level shifter and sourcing 5 volts
• On a new board, assume some peripheral you need will be missing its driver, and plan time for it

The dead end

The LD06 is a cheap, popular 360-degree lidar, and like a lot of inexpensive serial peripherals it talks over USB through a CH340-class serial chip. On a normal Linux system the ch341 driver claims that chip and hands you a serial port. The MediaTek Genio’s vendor kernel, trimmed for the platform, did not include that driver. So the lidar enumerated on the USB bus, the kernel saw a device, and no serial port ever appeared. Software that tried to open the lidar’s port found nothing there.

This is one of the most common surprises on a new embedded board. The hardware is fine, the sensor is fine, and a missing driver makes the whole thing invisible to your application.

Route one: build the driver

The direct fix is to build the missing driver as an out-of-tree kernel module against the exact kernel on the board, then install it so it loads automatically. That sounds routine and has two real snags. First, you need the vendor’s kernel headers and configuration to build a module that will actually load, and vendors do not always hand those over without a reason, so asking with a concrete need helps. Second, the module has to match the kernel’s build options, and there is a specific trap around how the kernel handles module type information that will stop an otherwise-correct module from loading if you miss it. Once those line up, the driver loads at boot and the lidar becomes a normal serial port.

We keep the specifics of that build, the exact configuration and the trap, for the work we do, because it is precisely the kind of thing that turns a lost week into an afternoon when someone has hit it before.

Route two: skip USB entirely

The other route is to not use the USB-serial chip at all and wire the lidar directly to a hardware UART on the carrier board. That removes the driver problem completely, because a hardware UART is a first-class serial port with no chip in between. The cost is on the electrical side. The board’s UART may run at a different logic voltage than the sensor expects, in which case you need a level shifter so you do not feed the wrong voltage into a pin, and you have to find a 5-volt source on the carrier to power the sensor, since not every header provides one. It is more wiring and a meter check, and it sidesteps the kernel entirely.

Which route is right depends on whether you would rather own a kernel module or a bit of wiring, and on what your carrier board exposes.

The takeaway

The real lesson is the one at the top: on a new board, budget for the fact that some peripheral you need will arrive with no working driver, and the failure will look like dead hardware rather than a missing piece of software. Recognizing that pattern fast is most of the fix.

Bringing up sensors and peripherals on a fresh board, MediaTek Genio or NVIDIA Jetson, is a large part of what we do, and it is where the schedule risk on a new platform lives. Tell us what you are building and we will get your sensors talking. For the whole robot, see the ROSOrin build overview.