# PiLiDAR: a DIY 360-degree scanner for Raspberry Pi

> PiLiDAR combines a rotating LDRobot sensor, a Raspberry Pi camera and Python-based reconstruction into one DIY scanning system. It is aimed at experimenters who can assemble and calibrate the hardware, accept a work-in-progress workflow and may need a PC for the heaviest 3D processing.

**PiLiDAR/PiLiDAR** — an open-source, low-cost DIY 360° LiDAR scanner and panoramic 3D reconstruction system.

- Repository: https://github.com/PiLiDAR/PiLiDAR
- Stars: 2,005 · Forks: 97
- Language: Python
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/pilidar-pilidar

## PiLiDAR's rotating LiDAR and panoramic reconstruction pipeline

PiLiDAR addresses a specific gap between a single-direction distance sensor and a complete spherical scan. It is intended for makers, educators and hobbyists who can build a Raspberry Pi 4 system around an LDRobot LD06, LD19 or STL27L sensor, an M12-lens camera, a stepper motor and an MPU 6050-based GY-521 accelerometer. The repository describes itself as work in progress, so it is better understood as an accessible scanner design under development than as a packaged consumer product.

The capture process is assembled from several distinct stages. A custom Python serial driver reads distance samples from the LiDAR and checks package integrity with a CRC operation. Hardware PWM controls the motor through `rpi_hardware_pwm`, with calibration based on curve fitting. The script can display the two-dimensional scan live and export samples through NumPy or CSV. This separates raw planar ranging from the later panoramic and 3D stages.

A camera fitted with the ArduCam M12 lens supplies the visible imagery. PiLiDAR uses Hugin to stitch fisheye photographs into a 6K 360-degree spherical image. It reads automatic exposure from EXIF data and applies iterative optimization to obtain more consistent white balance. The system then builds 3D scenes from 2D planes according to camera angles and offsets. Point colors come from the panorama, while Open3D handles visualization and export to PCD, PLY or E57. Multiple scenes can be aligned through global registration followed by ICP refinement.

This architecture is useful because it keeps each stage distinct while allowing them to form one scanner workflow. It also exposes costs that a finished commercial scanner can hide. The motor, camera, power conversion, sensor, printed gearbox and software configuration all become part of the user's system rather than a sealed appliance.

## LD06, LD19 and STL27L choices in PiLiDAR

PiLiDAR supports three LDRobot devices, but the repository's detailed specifications cover LD06 and STL27L. The listed LD06 samples at 4,500 Hz with a baud rate of 230400, while STL27L samples at 21,600 Hz with a baud rate of 921600. The README also lists LD19 as supported, but it does not provide a separate LD19 specification section. That distinction matters for builders comparing range, angular resolution and serial requirements.

The hardware bill of materials includes one LDRobot unit, a Raspberry Pi HQ Camera with ArduCam M12 lens, a Raspberry Pi 4, a NEMA17 42x42x23 stepper and an A4988 driver. Power can use two 18650 cells with a step-down converter or a 10,000 mAh USB powerbank with a step-up converter. The README estimates approximately $200 to $280 in April 2025, excluding the power supply. It explicitly says its purchase links are examples rather than a recommended purchasing route, so the quoted total should not be treated as a fixed procurement specification.

The serial connection uses UART, while motor control uses hardware PWM and GPIO. PiLiDAR also relies on a GY-521 accelerometer at I2C address `0x68` to provide orientation-related data. For LD06 and STL27L wiring, the documented signals are UART TX, PWM, ground and 5 V power. On the Raspberry Pi, the listed connections include UART0 Rx on GP15, PWM0 on GP18, the scan button on GP17, and A4988 direction and step signals on GP26 and GP19.

Because the project is assembled from separate modules, matching sensor protocol matters. The driver must match the selected model, and the motor calibration must match the actual gearbox, load and voltage. The README does not document an automated hardware compatibility check.

## PiLiDAR Raspberry Pi configuration and button service

The README provides Raspberry Pi configuration steps, but it does not include a repository clone command or a complete Python package installation command. It points to `requirements.txt` for dependencies and provides wiring addresses, service configuration and diagnostic commands. The following is therefore the documented setup sequence, rather than a complete deployment guide.

First enable GPIO shutdown in the firmware configuration as shown by the README:

```bash
echo "dtoverlay=gpio-shutdown" >> /boot/firmware/config.txt
```

PiLiDAR then uses GPIO22 for SDA and GPIO27 for SCL because the power button occupies GPIO3. The README says to disable the default I2C controller and enable the custom bus:

```ini
dtparam=i2c_arm=off
dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=1,i2c_gpio_sda=22,i2c_gpio_scl=27
```

After applying the firmware settings, the documented bus scan should be run from the Raspberry Pi:

```bash
sudo i2cdetect -y 3
```

The next documented use is registering the scan button. Make the interrupt script executable:

```bash
chmod +x gpio_interrupt.py
```

The README uses `pilidar.service` for autostart. Create the service file at the documented path, `/etc/systemd/system/pilidar.service`. Its configuration starts `gpio_interrupt.py` as user `pi`, sets `LG_WD=/tmp`, and disables automatic restart:

```ini
[Unit]
Description=PiLiDAR-Button
After=network.target

[Service]
Type=simple
User=pi
Environment=LG_WD=/tmp
ExecStart=/usr/bin/python3 /home/pi/PiLiDAR/gpio_interrupt.py
Restart=no

[Install]
WantedBy=multi-user.target
```

After creating the file, reload systemd, enable the service and start it:

```bash
sudo systemctl daemon-reload
sudo systemctl enable pilidar.service
sudo systemctl start pilidar.service
```

The README also documents temporary UART permissions with `sudo chmod a+rw /dev/ttyS0`. It presents a `sudo visudo` entry as an older permanent workaround, but does not resolve the security tradeoff of granting passwordless permission changes.

## PiLiDAR capture timing and computational boundaries

PiLiDAR documents a capture sequence with substantial fixed and variable stages. The README lists 12 seconds for initialization, 17 seconds for shooting four photographs, 1 minute 24 seconds for a scan at 0.167 degrees by 0.18 degrees, and 37 seconds for stitching and cleanup. These figures describe the documented sequence, not a universal completion time for every scene or Raspberry Pi configuration.

The motor uses an A4988 driver and a NEMA17 stepper with a 3D-printed planetary reduction gearbox. The gearbox is part of the scanner design rather than an optional software detail. A wrong reduction ratio, loose belt, motor current setting or mechanical play can affect angular positioning. The README mentions PWM calibration with curve fitting, but it does not provide a calibration command or explain the acceptance criteria for a completed calibration.

The 3D stage is heavier. Open3D performs registration, ICP refinement, visualization and export. Poisson Surface Meshing is available, but the README warns that it is very slow on a Pi 4 and recommends running that operation on a PC. This division makes sense: the Raspberry Pi can remain the capture computer while a workstation handles the most expensive reconstruction step.

The pipeline is not fully automatic in the sense of a one-click commercial product. Users must account for stitching, scene offsets, registration quality, point-cloud artifacts and meshing time. The README does not document automatic mesh quality checks, confidence thresholds, automatic retry behavior or a rollback mechanism for failed scans.

## PiLiDAR's practical limits compared with a dedicated scanner

PiLiDAR is a reasonable alternative to a dedicated 360-degree LiDAR scanner when the objective is to build or understand the system. A commercial scanner can provide an integrated enclosure, calibrated electronics and a simplified workflow, but the repository does not describe PiLiDAR as competing on measurement guarantees or deployment convenience. Its documented advantages are openness, component choice and access to the processing code.

The main limitation is hardware integration. The user must assemble a mechanical rotation system, wire the LiDAR and A4988 correctly, configure the camera and accelerometer, calibrate PWM and choose a power design. The README's $200 to $280 estimate covers parts only, excludes the power supply and depends on April 2025 pricing. It does not include enclosure machining, connector quality, shipping, taxes or the labor required to assemble and troubleshoot the system.

A second limitation is processing time and reliability. Poisson meshing can be slow on a Pi 4, while registration and stitching introduce stages where poor inputs may produce unusable geometry. The README shows preliminary single scans with no registration or post-processing, so its published examples should not be interpreted as evidence of a finished production pipeline.

The alternative is a dedicated commercial panoramic or LiDAR scanner that handles hardware integration and calibration as a product. PiLiDAR makes more sense when the builder values control over sensors, scripts and point-cloud formats, or when the scan setup must be customized around a Raspberry Pi. The repository does not provide accuracy figures, benchmark results, a formal tolerance specification or a documented comparison with commercial devices.

## PiLiDAR licensing and maintenance state

The repository is not archived, and its last push was on 2026-10-15. There are no GitHub releases. That means the project can receive repository changes, but users should not assume that released versions, migration notes or upgrade paths exist. The absence of releases also makes it important to record the exact commit used for a scan if reproducibility matters.

The repository identifies its license as a custom license that GitHub cannot classify, with the terms in `LICENSE.md`. This review cannot summarize those terms without the file contents. Before using PiLiDAR commercially, redistributing modified code or incorporating its code into another project, read `LICENSE.md` directly. A custom license may impose conditions that differ from common permissive licenses, and its classification in GitHub is not a substitute for the license text.

Upgrading also has a software cost. The dependency file includes version floors for packages such as `open3d>=0.18.0`, `opencv-python>=4.10`, `scipy>=1.12.0` and `plotly>5.24.0`, but the README does not provide a release-specific upgrade procedure. Because the repository has no GitHub releases, there is no documented compatibility matrix for migrating between revisions.

## Conclusion

PiLiDAR suits Raspberry Pi builders who want to construct a low-cost panoramic scanner and are prepared to handle wiring, calibration and computationally heavy reconstruction. It is a poor fit for users needing a turnkey commercial scanner, a documented rollback path or a fully automated capture-to-mesh workflow. Before adoption, verify the custom LICENSE.md terms, reproduce the hardware wiring for the chosen LDRobot model, and confirm that your camera, motor and accelerometer positions match the script assumptions.

## FAQ

### What hardware does PiLiDAR require?

The documented hardware includes an LDRobot LD06, LD19 or STL27L, Raspberry Pi HQ Camera with ArduCam M12 lens, Raspberry Pi 4, NEMA17 stepper, A4988 driver and a power arrangement. The repository lists GY-521 accelerometer wiring as part of the setup.

### Can PiLiDAR export 3D point clouds?

Yes. The README documents Open3D visualization and export to PCD, PLY or E57. It also describes global registration and ICP fine-tuning for aligning multiple scenes.

### Is PiLiDAR suitable for a Raspberry Pi 4?

Yes, Raspberry Pi 4 is listed in the bill of materials, but Poisson Surface Meshing is documented as very slow on that platform and is recommended for a PC. The project is still labeled work in progress.

## Sources

- [Issues](https://github.com/PiLiDAR/PiLiDAR/issues)
- [PiLiDAR/PiLiDAR on GitHub](https://github.com/PiLiDAR/PiLiDAR)
- [README](https://github.com/PiLiDAR/PiLiDAR/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pilidar-pilidar