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, 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 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 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

Bare-earth lidar shows the whole shape of Winsor Dam, an earth fill embankment of roughly 4 million cubic yards, 2,640 ft long and 170 ft above the Swift River. It holds back the Quabbin Reservoir, Boston's water supply. In April 1938 Massachusetts disincorporated Dana, Enfield, Greenwich and Prescott so the valley could go under, and around 2,500 people lost their homes.
Work ran from 1935 to 1939 under chief engineer Frank E. Winsor, who it's named for.
The dam is the long diagonal embankment from the bottom middle to the top, with the stepped downstream face showing as parallel bands.
Winsor Dam's earth embankment across the Swift River valley
Same view as plain hillshade with elevation tint
Air photo of the same area, August 2023
Numbered pins on picture 1:
Pin 1: The dam's stepped downstream face
Pin 2: Flat Quabbin Reservoir surface
Pin 3: A deep straight cut channel
Lidar: USGS 3D Elevation Program (3DEP), public domain.
Imagery: USGS The National Map (NAIP Imagery service), 2023, Public domain.

After my Ouster OS0 mapping experiment, I tried reconstructing the same kind of indoor space from phone video alone. The goal is eventually to combine measured LiDAR geometry with the splat’s appearance; that fusion is not done yet.

The successful one-room capture was 48.6 seconds at 4K/59.94 fps. COLMAP registered 187/195 selected images and produced 51,475 sparse points; Brush trained 400,000 Gaussians. An earlier apartment walkthrough only reconstructed part of the space.

The key distinction for this community: no LiDAR data went into this reconstruction. Its scale is uncalibrated. A convincing render is not a metric point cloud, and the splat is not a conventional textured mesh. Unseen surfaces are still uncertain. This does not establish that camera reconstruction replaces LiDAR.

For the next step I want to establish scale and registration against the Ouster map, then evaluate residuals on held-out geometry rather than just picking a visually pleasing overlay. I’d be interested in practical experience with splat-to-LiDAR registration, especially indoors with weak texture or incomplete overlap.

I made a 2:20 video showing the source capture, actual reconstruction, limitations and next experiment: https://www.youtube.com/watch?v=mFwu5Y54c3o

Disclosure: my project and video, with AI-assisted editing and my authorized synthetic narration.

TL;DR: Aeva presents its CityOS traffic-intelligence platform and intersection LiDAR at the New England ITS 2026 show tomorrow in Manchester, NH. Sivers supplies the lasers and optical amplifiers inside Aeva's lidar, with production ramping from Q4 2026 — so smart-intersection deployments are another volume driver for Sivers content. Not an order, but another lane opening up for the same hardware.

Saw this on X: $AEVA just announced it's attending the New England ITS 2026 Annual Interchange on October 8 — that's tomorrow — at the DoubleTree in Manchester, NH. On the agenda: their AI-powered real-time traffic intelligence platform, Aeva CityOS, plus LiDAR detection solutions for signalized intersections. Eric Gannaway is presenting in Session 2B, and they're appearing alongside Ocean State Signal.

The read: "LiDAR with $SIVE."

Here's why that matters. Sivers is in Aeva's lidar chain — the March announcement had their "strategic LiDAR customer" (read: Aeva) incorporating Sivers lasers and optical amplifiers across its platforms, with production ramping from Q4 2026 and an estimated $53–138M of cumulative value over the product lifecycle. CityOS is the smart-city/traffic side of Aeva's business, and every signalized intersection running Aeva detection is another lidar unit with Sivers content in it.

Caveat, as always: a conference appearance is not an order, and this is the traffic-intelligence vertical, adjacent to (not the same as) the automotive and robotics lidar ramp already on the calendar. But it's another demand vector for the same Sivers-supplied hardware, in a market — intelligent transportation — that buys in municipal volumes once it moves.

Sources & credits: spotted via a post by @Sofigoodboy on X (https://x.com/Sofigoodboy/status/2107900599752950182); Aeva's Sivers lidar-chain details from the March 2026 Sivers announcement.

I have been experimenting with an OS0-128 and an old Samsung S10. The phone makes a useful portable display, but getting a stable accumulated map has been a separate problem.

The data path is OS0 → Mac → browser viewer on the S10. Processing runs on the Mac; this is not a claim that the phone runs LiDAR SLAM. The actual phone recording displays roughly 21k points.

The main integration catch: our sensor was on firmware 3.1.0 with legacy IMU packets. The mapping software reported that its synchronized IMU path required a newer firmware/data format and used constant-velocity deskew instead. One saved cloud reached about 461k points before a pose discontinuity stopped further integration. We did not implement global loop closure.

I documented the original recording, saved cloud, and what failed here: https://www.youtube.com/watch?v=Sv_YqGQpgoM

This is my own experiment/video. The measured cloud and phone footage are real; diagrams are illustrations and narration uses my authorized AI voice.

My next idea is to match camera-derived geometry from the phone against a stable LiDAR map. That is still a proposal, not a demonstrated result. Before that, I want to verify the synchronized IMU/deskew path and repeat the same trajectory reliably. If you have used this generation of OS0 for indoor mapping, I would be interested in the diagnostics you used to distinguish timing/deskew trouble from scan-registration failure.