I build active-safety and driver-monitoring systems, and I test them hard enough to find out where they fail.
An end-to-end driving stack in the CARLA simulator: multi-sensor perception, a geometry-first emergency braking corridor swept through LiDAR rather than gated on a detector, a committed safety arbiter, and a reinforcement-learned cruise controller that only proposes a speed, clamped under a safety cap. Simulation only — nothing here has run on a vehicle.
The history behind these numbers: an early run also reported 45/45, but with the reaction-delay criterion effectively switched off — the harness had no hazard origin to time from, so it could not fail. Once that was fixed, the 2026-09-19 run gave 43/45 and a failed gate. A later review of my own harness found more places where a missing or invalid measurement could count as a pass; after fixing them, the 2026-09-27 re-run gave the 45/45 above. That does not mean the late reaction is fixed: the same pedestrian case took between 0.5 and 1.225 s across runs and still fails in storm, and one run per case cannot separate a fix from luck. It stays an open finding.
A decision I made: braking triggers on a LiDAR/radar corridor check, not on detector confidence, so with the same geometry, path and sensor data a missed bounding box does not by itself remove a brake request. It still depends on valid range data and on the selected lane, and on a sensing envelope of about 30 m ahead. The learned cruise controller only proposes a speed under that envelope.
A driver-state layer that sits above the ADAS and reads the person as well as the road: eyelid closure over a rolling window, the longest unbroken closure, and jaw opening — then explains every intervention in one sentence. Runs locally in Python; it has not been measured on embedded hardware.
Read the first column as the real result: on drivers the model has never seen, this problem is hard, and the honest score is near the low end. The control experiment in the third column is the reason the numbers are reported this way — the same pipeline evaluated carelessly would have produced 99%, and that 99% would have meant nothing.
A decision I made: validation folds are split by driver, not by frame. Splitting by frame puts the same person on both sides and turns a memorised face into an apparent result.
Eye-state stage on strangers: on 13 people from the DMD dataset, leave-one-person-out, the eye open/closing/closed/opening classifier reaches 0.87 balanced accuracy, and the PERCLOS it produces is within 0.023 of the annotated value on average. Every recording is a parked car, and DMD has no drowsiness label, so this says nothing yet about drowsiness accuracy on the road.
The rule engine's demo on 6 labelled drives (3,600 frames at 20 fps) flags 2,083 of 2,100 impaired frames and 147 of 1,500 clear frames. Those thresholds were not tuned on held-out drivers, and neighbouring frames are not independent, so these are demo figures for six people — not a population rate, and not a measure of how often a driver would get a false alert per hour.
Wheel-mounted electrostatic capture for tyre and road-wear particles, with an ESP32 → MQTT → Supabase pipeline and a Flutter app for fleet operators. My part: the ESP32 code that reads the sensors.
Speech-to-text and translation running fully offline, so no audio leaves the device: Whisper with a LoRA adapter and NLLB for translation. No accuracy figure is claimed here.
Perception, sensor fusion and committed active-safety arbitration, validated in simulation.
Detection, tracking and lane estimation — resolved into metric range, not just boxes.
ESP32 sensor reading inside a telemetry pipeline (MQTT, time-series backend). Growing this area next.
On-device models, and the evaluation discipline that tells you whether they actually work.
Happy to walk through any number on this page and show you where it came from, including the ones that got worse.