Writing a Lidar Driver From the Serial Protocol Up

The RPLIDAR A1M8 is a small spinning laser rangefinder: a Class 1 infrared laser at 785 nm on a turntable, measuring distances from 0.15 to 12 metres while rotating about 5.5 times a second. Slamtec ships an SDK for it. I wanted to understand the device at the byte level, so I wrote a driver in plain Node.js that speaks its serial protocol directly, with no vendor SDK and no native dependencies beyond the serial port itself.

What comes over the wire

The sensor talks through a USB-to-UART bridge at 115,200 baud. In standard mode each measurement is a 5-byte record of angle, distance, and quality, which caps the rate around 2,000 points per second. Express mode packs 32 samples into 84-byte capsules for about 4,000 per second. Boost mode reaches the sensor's rated 8,000 samples per second with 132-byte ultra capsules holding 96 samples each.

Boost was the interesting one to implement. At 8,000 samples per second, five bytes per sample would need far more bandwidth than the serial link has. The ultra capsules fit by delta compression: each group stores one major distance on a variable bit scale plus two 10-bit deltas, and the decoder reconstructs the rest. That uses about 96 percent of the link's capacity. The driver tries boost first and falls back to express and then standard if the device refuses.

At full rate that is roughly 1,450 points per revolution, a point every quarter degree.

Testing without the hardware

Most of the driver was written against a mock device that emits the same bytes the real sensor does, describing a 6 by 4 metre room with a pillar and a doorway. The serial port library loads lazily, so the mock and the unit tests run with zero native dependencies. The scan below is a simplified browser version of that mock room, sampled at the standard-mode rate.

Persistence controls how long each point stays on screen. Short persistence shows the sweep itself, and longer persistence builds up the outline of the room. Raise the noise and the walls thicken into the fuzz real scans show on dark or glossy surfaces. The pillar casts a shadow because the sensor sees only the first surface along each ray, so whatever sits behind it stays missing until you move the sensor.

Mapping

The repository also includes a hector-style scan matcher that aligns each new revolution to the map built so far, so a handheld sensor can sketch a floor plan as you walk. It has no loop closure, so drift accumulates over long paths, and it works only when the sensor is held level, moved slowly (under about a metre per second), and kept at a roughly constant height. A sweep mode extrudes scans into 3D and exports PLY point clouds. Its accuracy depends entirely on how steadily you move, because the device has no inertial sensor.

One hardware constraint shaped the driver. The USB adapter ties the motor to the serial DTR line, so scan rate cannot be adjusted over USB. The driver switches the motor on and off through DTR and leaves its speed alone.