How to use Claude to debug a LiDAR speed camera
Claude Code analyzed real TF-Luna drive-by logs, corrected sampling, and built a Pi dashboard; family tests still showed speed errors and missed plates.
blueprint.hackclub.com
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Inspect our TF-Luna drive-by logs alongside the sensor update rate. Check duplicate samples and background transitions before changing filters. Compare proposed thresholds against repeated reference-speed passes, preserve the baseline, and show remaining errors before we approve a new firmware revision.
Reach people exploring AI agents
See placements →What happened
The assembled camera produced vehicle photographs and more consistent speed estimates without the previous extreme outliers; individual readings remained inaccurate and license plates were not captured.
Reported by pro-grammer 🚀 — Hack Club BlueprintHow the agent did it
- The builder assembled the sensors and used Claude Code to write individual measurement tests.
- The family collected repeated drive-by logs, which Claude analyzed before revising sampling and thresholds.
- Claude added the local dashboard and startup behavior, while the builder inspected real readings and photographs.
Where a person stepped in
The builder assembled and aligned the hardware, reverted a worse revision, and collected reference-speed passes with their father before accepting the final behavior.
Odin’s Eye combined a TF-Luna distance sensor, camera, OLED and Raspberry Pi into a portable speed camera. The finishing journal shows Claude Code working from measurements collected on the assembled device. Initial speed estimates included extreme outliers, and a vague request to improve accuracy made detection worse. The builder reverted those changes.
A more useful loop followed. Their father drove past repeatedly near a target speed while the program saved distance, trigger and fit data. Claude examined those files and identified duplicate readings caused by polling faster than the sensor updated. The implementation discarded the initial background sample and adjusted the minimum distance-change threshold and speed scale using subsequent runs.
The large outliers disappeared, although individual estimates still differed from the reference. The last three phone-assisted passes reported 16, 15 and 18 km/h against a 20 km/h target.
Claude also implemented a local dashboard and startup behavior. Human assembly, driving and inspection remained essential. Capture timing improved enough to photograph the vehicle, but the license plate was missed; recognition remained future work.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Hack Club Blueprint · pro-grammer 🚀
Frequently asked questions
What improved the debugging feedback?
Repeated physical passes produced saved measurements that Claude could compare.
Were the speeds fully accurate?
No. The last three target-speed passes still reported lower speeds.
Did license-plate recognition work?
No. The photograph captured the vehicle, while recognition remained future work.
More details
About this account
The builder assembled the sensors and used Claude Code to write individual measurement tests. The family collected repeated drive-by logs, which Claude analyzed before revising sampling and thresholds.
Opened the dated finishing journal. Its measured outcome supersedes the project introduction’s aspirational license-plate claim. This is a DIY experiment, with imperfect reference speed and geometry, not certified traffic measurement. Suggested prompt written by Agents In Use; no original task prompt was found in the verified text.
Credit: pro-grammer 🚀 — Hack Club Blueprint
Source published 16 May 2026
Source checked 14 Oct 2026
Tools and topics
Claude Code · Raspberry Pi Zero 2 W · TF-Luna · Python
sensor calibration · speed camera · physical feedback
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.