The Tech StorytellerBook a call ↗
← Collaboration examples

OUSTER OS0 / INDEPENDENT SENSOR STORY

One sensor. Several engineering stories.

Independent editorial examples. These projects were not paid for by, sponsored by or affiliated with the featured manufacturers. They illustrate the format of a possible collaboration, not an existing client relationship.

The Ouster OS0 connects the camera-calibration experiments, an old-phone viewer and an office twin. Later episodes return to the same geometry—and use it to question what a smaller RGB + ToF sensor is really measuring.

Adding a person reveals incorrect colour assignment in the point cloud, despite improved room alignment.
EP03 · 3:40 · Recorded evidenceAdding a person reveals incorrect colour assignment in the point cloud, despite improved room alignment. Watch this moment ↗

EP03 → EP10

An overlay can fool you.

Selected alignment residuals improve, but moving people and a wrong camera pose expose the limits of judging calibration on flat walls.

EP04 → EP08

From a stream to a place.

A phone viewer becomes part of a longer story about sensor pose, measured geometry and a room robots can interact with in simulation.

EP14 → EP15

A reference for the next sensor.

The OS0 helps frame the smaller RGB + depth experiment, where camera alignment and depth distortion need separate tests.

The dedicated Onebox build page is here.
Pi rig, Mini, Mini-i and Mini-X design studies, with playable recordings from the real sensor bring-up. See the revisions and watch the prototype data →

CROSS-EPISODE FIELD NOTES · UPDATED 22 OCTOBER 2026

What changed across the episodes.

I first wanted to put colour on a point cloud. Over the next experiments, the OS0 became the geometry I kept coming back to: a stream to display, a room to reconstruct, a coordinate frame to recover, and a comparison for another depth sensor.

EP03 → EP04: getting points onto a screen was only the start.

In Episode 3, a low-cost Raspberry Pi camera met the OS0. Checkerboard and manual matching improved selected static-boundary alignment from about 13.5 to 4.2 pixels. The person ghost did not disappear. That split mattered: a better fit on the room did not solve timing or decide which surface the camera could actually see.

Episode 4 moved the data to an old Samsung S10 through a Mac bridge. It made a useful handheld viewer, but pose jumps, IMU compatibility and a disappearing Ethernet adapter interrupted the bigger mapping idea. The phone was displaying scans; it was not localising itself in the map.

The Samsung S10 displays live LiDAR through the Mac bridge; processing stays on the Mac.
EP04 · 1:28 · Recorded evidenceThe Samsung S10 displays live LiDAR through the Mac bridge; processing stays on the Mac. Watch this moment ↗

EP08 → EP10: a room map becomes something to align against.

In Episode 8, the static scan supplied geometry for the office twin while phone video supplied appearance. Those captures were four days apart. Their different roles—and the work of aligning them—became part of the experiment instead of disappearing behind a polished rendering.

By Episode 10, the setup had moved. Bringing the live sensor back into the old map meant recovering its pose and fitting the iPhone view again. The first wall alignment looked convincing while putting the camera in the wrong physical place. Later iterations used scene features and my moving silhouette across 244 frames.

The saved third iteration reported about two pixels of residual on the room features and a time offset near −1.1 seconds within that recording, using estimated camera intrinsics. My LiDAR body clusters then became a rough avatar. Heading flips and missing anatomy showed why a plausible moving character is a different result from a fully observed person.

The room begins as an Ouster OS0 point cloud, before object behaviour is added.
EP08 · 1:33 · ReconstructionThe room begins as an Ouster OS0 point cloud, before object behaviour is added. Watch this moment ↗
Version 1 and version 3 are compared on the same moving-person footage.
EP10 · 8:05 · ReconstructionVersion 1 and version 3 are compared on the same moving-person footage. Watch this moment ↗

EP14 → EP15: the one-box idea inherits these questions.

The repeated integration work led to the RGB + depth module idea: a camera, depth sensor and IMU with a shared clock and known alignment. Episode 14 brought up an epc660-class iToF sample beside a Pi camera. Calibration improved from 12.7 to 4.56 pixels but missed the stated acceptance thresholds. That was a separate sensor experiment, not an OS0 upgrade.

In Episode 15, the iToF sensor bowed a wall by 12–14 cm across roughly 4.5 m while the Ouster showed it straight. Exposure changes reduced noise, but modulation frequencies still disagreed on distance. A correction fitted to that one wall improved plane RMS locally; it did not establish accuracy across ranges. The next useful tests are a range sweep and a spill test, followed by a dToF comparison.

Landmarks are placed between the infrared and RGB views for provisional alignment.
EP14 · 11:10 · Recorded evidenceLandmarks are placed between the infrared and RGB views for provisional alignment. Watch this moment ↗
A top-down comparison shows the iToF wall bowed against the Ouster reference.
EP15 · 3:50 · Recorded evidenceA top-down comparison shows the iToF wall bowed against the Ouster reference. Watch this moment ↗

What this sequence taught me.

Keep three questions separate: where the camera and LiDAR are, when they observed the scene, and which surfaces each could see. Then check the depth measurement itself. Improving one layer can make the picture look better while another layer remains wrong.

HOW THIS COULD WORK FOR YOUR TEAM

The format,
adapted to your technology.

For a sensor manufacturer, this format can produce a technical explainer, integration footage, a multi-episode product story and developer-facing clips.

Explore the offer→

Pricing on request

LET’S BUILD A USEFUL STORY

Your technology.
A real application.

Bring a product, a workflow or an engineering question. We agree the experiment, deliverables, publication and usage before the work starts.

Discuss a collaboration↗

Pricing on request · lukas@alphavant.com