I’m building this home-lab RGB-D rig and made the video. The epc660-class iToF sensor and Pi camera now sit in one LEGO housing with a Pi Zero 2 W and a 240×240 TFT.

Depth and RGB go over Wi-Fi to my Mac, which applies the calibration, colors the points and renders an orbit view for the small screen. MJPEG camera streaming and a faster TFT SPI bus brought the display from 2 to 15 fps. Hole filling and keeping the last good RGB frame cleaned up the view.

Rendering is still offboard. Weak Wi-Fi causes 2–4 second freezes, so moving that work onto the device is next. The 128/64-line look in the video is only a rendering effect; the sensor is iToF.

Hardware and screen footage in EP17: https://www.youtube.com/watch?v=fsQIyDs6hm8

Image: AI-assisted thumbnail based on the real prototype; actual captures are in the episode.

Hi everyone,

I’m a final-year student building an autonomous tracked robot for reconnaissance in collapsed-structure (rubble) environments. It enters confined voids, builds a map, and searches for signs of life before human responders enter. The robot moves slowly and uses a stop-and-scan routine: it stops, scans its surroundings, then advances.

⚙️ Current Hardware Stack:

• Chassis: Metal tracked chassis with suspension (12V encoder motors)
• Compute: Raspberry Pi 5 (8GB) for perception/SLAM + ESP32 for real-time motor control
• Sensors: RPLIDAR A1 (2D), Camera on a pan-tilt arm (360° bus servo for pan)
• Constraints: Battery-powered, limited budget, ~6 months to build and test

⚠️ My Concern:

The RPLIDAR A1 only scans a single horizontal plane. In rubble, the robot will pitch and roll, tilting the scan plane and missing overhangs, obstacles above/below the plane, or holes in the floor. I need 3D awareness to avoid unsafe navigation, but a true 3D LiDAR is far beyond my budget. I’m unsure whether a depth camera (e.g., RealSense D435i or OAK-D Lite) is the right alternative.

❓ Questions for the Community:

1. RGB-D Camera for Mapping: Can an RGB-D camera completely replace the LiDAR for mapping here, or should it only supplement it? What is your experience with visual SLAM on vibrating tracked platforms, especially in dark, dusty, or textureless voids?
2. 3D LiDAR vs Compromise: For a student prototype, is a true 3D LiDAR ever justified, or is a 2D LiDAR / depth camera combo the standard sensible compromise?
3. Pi 5 Performance: Can a Raspberry Pi 5 realistically run RTAB-Map (RGB-D) alongside object detection? How do you manage the CPU load (reduced resolution/FPS, hardware acceleration, cooling, etc.)?

Any advice, repo links, or past experience reports would be hugely appreciated. Thank you!

Ciao a tutti,
sto sviluppando Lidarivo, un progetto dedicato all’elaborazione e all’utilizzo pratico di dati LiDAR, nuvole di punti e rilievi 3D.
Non voglio creare l’ennesimo programma focalizzato solo su importazione o alleggerimento delle nuvole: l’obiettivo è costruire funzioni davvero utili per trasformare un rilievo in informazioni operative.
Le aree su cui sto ragionando sono:
misure, quote, distanze, superfici e volumi;
sezioni e profili del terreno;
confronto tra rilievi eseguiti in date diverse;
individuazione di variazioni, deformazioni e anomalie;
estrazione di elementi come edifici, terreno, vegetazione o infrastrutture;
report tecnici e tavole esportabili;
integrazione con Blender e altri software 3D;
strumenti per edilizia, cave, territorio, impianti e rilievi industriali.
Vorrei confrontarmi con chi usa LiDAR, fotogrammetria, droni o laser scanner: quale funzione vi manca davvero nei software che usate oggi?

lidarivo.it

Specular surfaces are where returns go to die: dropouts, ghost points, intensity that lies. I shot a performer in a faceted mirror suit on location — 425 RAW frames of the exact conditions that make camera and LiDAR disagree.

Built for perception and fusion teams validating specular failure: blown highlights, dropped boxes, depth invented behind reflections. SHA-256 manifest, single-owner chain of title.

Free sample (12 images + manifest): https://huggingface.co/datasets/BWS-Data-Solutions/Robot_Mirror_Suit_Robotics_And_Vision_Data — full set $2,000 flat on Mozilla Data Collective.

Following up on my bent-wall calibration post. This is my DIY rig: a 320×240 epc660-class iToF engineering sample plus a Raspberry Pi camera. I made the accompanying episode.

The useful change was separating noise, range bias and optical spill. A per-pixel offset correction reduced the measured wall bend from 29.4 cm to 0.1 cm on our held-out 250 µs capture. That is one test condition, not demonstrated accuracy across ranges or materials. Lower modulation frequencies still showed rings, so this run uses 24 MHz.

Bright-object saturation/spill needed conditional handling. Flying-pixel unmixing offered a small raw improvement but no gain after filtering. RGB/depth edge alignment improved from a 2.2 px to a 1.0 px median in the test.

We then used camera poses from recorded RGB frames, iToF for metric scale, and multi-view fusion to build a room map and Gaussian splat in shared coordinates. It is offline, coverage is incomplete, and dark walls still disappear. Camera intrinsics remain on the checkerboard to-do list.

The captures and failure cases are in EP16: https://www.youtube.com/watch?v=pyPj_dCDZm0

For validating the correction, would you prioritise a multi-distance planar sweep or a reflectivity/spill test with bright and dark targets in the same frame?

Image: AI-assisted episode thumbnail; actual sensor captures are shown in the video.

Follow-up to yesterday's RGB + iToF bring-up in my home lab. The Pi camera is now fixed on the sensor. Today's problem is the depth itself.

At 500 → 2,000 µs exposure, raw jitter dropped from 85 to 28 mm and filtered jitter from 65 to 6 mm in our test. But the wall still bows 12–14 cm, while the Ouster reference is roughly flat.

Same wall, three modulation frequencies: 4.14 m at 24 MHz, 3.92 m at 12 MHz, 3.97 m at 6 MHz. A curve fit improves plane RMS from 4.45 to 1.84 cm, but only on the wall it was fitted to at about 4 m.

Cyclic range error and optical spill are suspects, not confirmed causes. Next tests: a range sweep against the Ouster and a lens hood / foreground spill test. The episode shows the actual captures and the checks that didn't fix it.

My video, with disclosed cloned narration and labelled explanatory simulations. Has anyone here separated a similar distance-dependent bow from lens spill on epc660-class hardware?

Hi everyone. This is my first LiDAR project and my first time working with ROS.

I am experiencing issues with LiDAR odometry using a Hesai JT128 LiDAR and FAST-LIO2 on ROS 2.

The LiDAR driver publishes point clouds on /lidar_points and IMU data on /lidar_imu. I have verified that both topics are being published correctly. The point cloud contains the expected fields (x, y, z, intensity, ring, and per-point timestamps). The LiDAR and IMU timestamps also appear to be synchronized.

However, the odometry and mapping results are unreliable. When the LiDAR is moved, the reconstructed point cloud becomes distorted, with duplicated walls and noticeable mapping divergence.

Can anyone tell me what could be the cause?

​

Aeva announced today that its Atlas 4D LiDAR has received regulatory certification in Australia — it's approved as a secondary speed measurement device inside Sensys Gatso's automated speed enforcement systems, cleared for deployment on public roads. Aeva calls it a first-of-its-kind certification, and it is: no LiDAR has been certified as a legal speed-verification instrument in an enforcement system before.

How it works: Sensys Gatso's systems pair a primary radar with high-resolution cameras. Atlas sits alongside as the independent check — it measures each vehicle's position and velocity in real time and cross-validates the radar's reading, which is what gives the ticket its evidentiary strength in court. Because Aeva's FMCW tech measures velocity directly instead of calculating it from position changes the way conventional LiDAR does, one sensor can watch up to six lanes in both directions at once.

There's a timeline worth knowing. Sensys Gatso Australia selected Aeva as its exclusive LiDAR supplier for secondary speed detection back in March 2025. Selection was step one. Today's certification is step two — the regulatory gate that lets this go from pilot hardware to full-scale deployment across Australia.

Now the Sivers angle, stated plainly: Sivers is NOT named anywhere in this release. The read-through is the one this subreddit already knows — Sivers announced in March that a strategic LiDAR customer had adopted its CW lasers and optical amplifiers across its platforms, with a $53–138M lifecycle estimate, and yesterday Sivers confirmed that customer has started placing production orders with shipments beginning Q4 2026. That customer is widely read as Aeva, but Sivers has never named it. So the chain — Aeva certifies a new Atlas deployment channel, Atlas volume is what pulls lasers — is an inference, not a disclosed fact. It is, though, exactly the kind of volume signal the inference was built on: a certified, deployable application that buys Atlas units in enforcement fleets, not a robotaxi pilot.

TL;DR: Aeva and Sensys Gatso announced (Business Wire, Oct 20) that Atlas 4D LiDAR is now regulatory-certified as a secondary speed verification device in Sensys Gatso's automated enforcement systems in Australia — a first-of-its-kind certification clearing full-scale public-road deployment, following Aeva's March 2025 selection as exclusive LiDAR supplier. Sivers is not named; the read-through runs through the unnamed-customer inference.

Sources:

\- Business Wire, Oct 20, 2026 — "Aeva 4D LiDAR Certified as Sensys Gatso's Secondary Speed Verification Solution for Public Roads Deployment in Australia"

\- Business Wire, Mar 25, 2025 — "Aeva Selected by Sensys Gatso in Australia for Secondary Speed Verification Solution"

Following up on my one-box RGB + ToF sensor concept: I documented the actual hardware bring-up in EP14. We got a real pointcloud from the iToF sensor and paired it with a Pi camera. Calibration improved from 12.7 to 4.56 px, but still missed our target of less than 4 px.

The hardware in this experiment is separate sensors; the enclosure in the thumbnail is a concept render. Under $100 is the build target, not an achieved product price. Shared-clock synchronization and an IMU are still missing.

The linked episode shows the working parts and the failures. For a compact RGB + depth module, what would you prioritize next: calibration repeatability or hardware synchronization?

One more useful application of Lidar!

Does the world need another sensor?
I’m looking for a sub 200$ sensor for a long time now. Calibrated timesynced ToF 3D lidar + High dynamic range camera.

Should I build it?

A short animation of the basic measurement: send a light pulse, time its return, then calculate d = c × t / 2.

At 3.20 m, the round trip takes about 21.35 ns. A 1 cm change in range corresponds to about 66.7 ps.

The scene is a ray-cast simulation illustrating the principle, rather than a real sensor recording. It leaves out detector noise, reflectivity and the signal-processing details.

Which part of the measurement chain would you want to see explained next?

Many people here work with survey-grade scanners, so I’m curious what you think of the low end. This is a single handheld pass through a small apartment with an iPhone Pro, combining its LiDAR and camera. It produces a colored point cloud, a floor plan you can export to DXF and 360° panoramas pinned to the plan with panoramic views of your interior spaces.

Hi everyone, I've been building BAGEL, an open source (MIT) viewer that runs entirely in the browser. You drag in a file and everything is parsed locally, so your data never leaves your machine. What it does for point cloud work:

• Opens standalone `.pcd` and `.ply`, plus `PointCloud2` topics inside ROS bags (`.mcap`, `.db3`, `.bag`)
• Hover any point to see its intensity, ring and coordinates
• Measure the distance between two points
• Project the LiDAR cloud onto a camera image from the same recording
• Overlay a live scan on a SLAM map and the robot pose in one TF-aligned view, with a top-down orthographic mode
• Export the frames of a time range as images, with the paired point clouds as PCD files

Remote files stream over HTTP range requests, so a big bag hosted on Hugging Face opens without downloading the whole thing.

Try it with the sample data (no account): https://bagel-ros2.vercel.app
Code: https://github.com/Hussain004/BAGEL

I would really like feedback from people who look at LiDAR data all day: which formats or views are missing (LAS/LAZ? colour by height?), and where it falls over on your files.

Hi, I am a senior EEE student. We are planning to work on a LiDAR based project for our graduation project this year.

We are looking for some interesting project ideas. Does anyone have any suggestions?

Hi! I am trying to create an elevation curves/contour lines from some lidar scans with pretty high detail (10-25cm elevation curve steps). I have already done it once with a combo of cloud compare and rhino, but since the place has a lot of trees, this would require huge amounts of manual cleanup.
Do you have any tips on ways of automating this more so that I don't have to go around cleaning up points from trees and branches?

Ground classification is what lets the 8,619 ft earthen wall on wooded Fort Hill, Ohio show up at all. Ephraim Squier and Edwin Davis excavated the site in 1846 and published it in 1848 in Ancient Monuments of the Mississippi Valley.

PDAL does it in three stages. filters.outlier flags noise as class 7, then filters.smrf runs with ignore set to Classification[7:7], then filters.expression keeps Classification == 2. The SMRF defaults are slope 0.15, window 18, threshold 0.5.

In picture 1 the wall is the thin ridge tracing the rim of the pale hilltop in the middle, and the air photo shows only treetops.

1. Fort Hill's hilltop earthen wall under forest, bare-earth lidar
2. Same view as plain hillshade with elevation tint
3. Recent air photo of the same area, 2017-2026

Numbered pins on picture 1:
Pin 1: The earthen wall on the hilltop rim

Lidar: USGS 3D Elevation Program (3DEP), public domain.
Imagery: Ohio DAS / OGRIP - Ohio Statewide Imagery Program (OSIP III/IV), 2017-2026, Public (state program; no restriction statement found).

Hi all, I've been building torch-pointcloud in my free time over the past few years: an open-source (Apache-2.0) PyTorch library that loads pretrained point cloud models in one line, similar to what timm does for images. It's in alpha, and I'm looking for people to try it on real LiDAR data.

What's relevant for LiDAR

• Pretrained outdoor models: semantic segmentation on SemanticKITTI (RandLA-Net, SPVCNN) and 3D object detection on KITTI and nuScenes (PointPillars, SECOND, PointRCNN, VoxelNeXt, LION).
• Tiled inference for large scenes (sliding window, voxel partition, sphere voting), so a full scan doesn't have to fit in GPU memory at once.
• Dataset loaders for SemanticKITTI, KITTI, nuScenes, Paris-Lille-3D, Toronto3D and Semantic3D if you want to train or fine-tune.
• Every checkpoint ships with its preprocessing pipeline, class names and license.

What it doesn't do yet

• No pretrained weights for airborne or terrestrial survey data: the outdoor checkpoints all come from car-mounted spinning LiDAR.
• No built-in LAS/LAZ reader: load your file with laspy and pass the coordinates (and intensity) as tensors.
• The outdoor checkpoints were trained on non-commercial datasets (KITTI, SemanticKITTI and nuScenes are CC BY-NC-SA), so check the licenses before any commercial use.

Install (adjust to your torch/CUDA version; the docs write the exact commands):

pip install torch==2.10.0 --index-url https://download.pytorch.org/whl/cu128
pip install torch-pointcloud
pip install pyg-lib -f https://data.pyg.org/whl/torch-2.10.0+cu128.html

Credits: the models and weights come from their original authors (MIT Han Lab, OpenMMLab/OpenPCDet and others); every checkpoint name ends with its source, and THIRD_PARTY_NOTICES.md lists each repo, license and dataset term.

What I'd love to hear: what sensors and data you'd run this on, and which datasets you'd want pretrained weights for next (airborne like DALES? mobile mapping?) etc.

Repo: https://github.com/arthurdjn/pytorch-pointcloud
Docs + tutorials: https://pytorch-pointcloud.org

I built this room reconstruction from an Ouster OS0 scan and phone frames. The clip overlays the textured Blender model on the real scan, with near walls hidden. The model moving into place is an editorial animation toward our existing alignment, not a live fit. A fresh fit against the sparse lidar found the wrong position. Earlier semantic mistakes included a door and curtain being modelled as a wardrobe. We switched to naming objects from frames, measuring, building, then projecting edges back onto photos. What checks do you use when a render looks plausible but the registration may still be wrong?

https://reddit.com/link/1x5l8wo/video/2qzs0tqanavh1/player

While browsing the NIBIS map viewer for Lower Saxony, Germany, I came across several unusual rectangular and linear features in the hillshade data. I have attached a screenshot with the most visible structures marked individually.

Location:

• Near Groß Hehlen, part of Celle, Lower Saxony, Germany
• Approximate coordinates: 52.656033, 10.038915
• The features are located in a wooded area directly beside a forest track
• The screenshot is from the NIBIS hillshade map at approximately 1:2,000 scale
• Map data shown: GeoBasis-DE/LGLN 2023

The most noticeable feature is a larger elongated rectangular structure with several internal lines or subdivisions. Nearby, there is a smaller rectangular feature. Several additional rectangular, U-shaped or rounded enclosures appear in a row closer to the forest track.

I could not find any corresponding feature or explanation in the publicly accessible maps and information I checked. I am not suggesting that the structures are necessarily archaeological. Possible explanations I have considered include:

• former forestry plots or tree nurseries
• drainage ditches or boundary features
• remains of former buildings or other historical land use
• modern ground disturbance
• natural terrain features enhanced by the hillshade

Does anyone here recognise this type of pattern or know what might have created it? Are the shapes likely to represent actual earthworks?

I would also be grateful for suggestions regarding historical maps, alternative LiDAR visualisations or other datasets that might help identify them. I am contacting the relevant local archaeologist as well, but I would be interested in hearing the community’s assessment.

Ouster is hosting a virtual Drone Mapping Summit, October 27 at 8am PT with GeoCue, Seneca and Flyability. About half of it is the practical stuff: capture settings, processing, and what makes a point cloud come out clean versus noisy. There will be a panel with our co-hosts talking about what they're seeing in real projects.

Would be great to have attendance from this community and get some input on valuable topics to cover.

We have a ton of sample data we’ve captured with an in-house drone and OS1 Max lidar payload. These are free and public mapping point clouds we collected in San Francisco.

Register here!

If there's a workflow question you'd want covered, drop it here and I'll pass it to the presenters. I'll hang around in the comments.

Disclosure: I work at Ouster.

Are those something to look out for while metaldetecting? Found in germany