CORRIDYX

Turn dash phones into a live, city-scale map of where camera-based autonomy can see

Status
Research
Version
1.0.0
Platform
Android app
License
MIT
01 · Problem

Road-quality-from-phones projects often blame the road for sensor faults, for example marking a road as having bad lane markings when the lens is dirty. CORRIDYX asks whether a camera can see a given stretch of road at a given time and weather, and invalidates samples when its own perception is compromised.

02 · Architecture

How it is put together.

CORRIDYX turns a dash-mounted phone into a corridor ODD (Operational Design Domain) scoring sensor. While the vehicle drives, it scores each ~150 m road segment on lane-marking visibility, GNSS quality, illumination, agent complexity, road roughness and perception weather, entirely on the phone with no video leaving the device. Its GLARYX subsystem scores the camera's own ability to see (lens dirt, glare, rain/fog, night quality), and samples taken while the camera is compromised are gated rather than scored against the road. Per-segment scores are exported as small numeric SegmentScorePackets that can be pooled across vehicles.

CaptureScoring headsSegment accumulatorPackets and storePrivacyUploadConditions APIframes + sensor dataframes + sensor dataper-frame metric samplesper-frame metric samplesSegmentScorePacket on segment exitSegmentScorePacket on s…blurred evidenceblurred evidencequeued packetsqueued packetsCaptureScoring headsSegment accumulatorPackets and storePrivacyUploadConditions APIframes + sensor dataframes + sensor dataper-frame metric samplesper-frame metric samplesSegmentScorePacket on segment exitSegmentScorePacket on s…blurred evidenceblurred evidencequeued packetsqueued packets
FIG. 01Modules and data flows, from the repository layout and documentation.
  1. 1

    Capture

    Camera frames, IMU, GNSS and light sensor input

  2. 2

    Scoring heads

    lanevis, gnssq, illum, chaos, rough and GLARYX perception-weather heads

  3. 3

    Segment accumulator

    Geohash-7 + heading segmentation, single-writer accumulator with gates

  4. 4

    Packets and store

    SegmentScorePacket build and Room persistence

  5. 5

    Privacy

    Face and plate blurring of evidence thumbnails

  6. 6

    Upload

    WorkManager packet upload, Wi-Fi only by default

  7. 7

    Conditions API

    Bound local service exposing PerceptionConditions to other apps

03 · Capabilities

Specification.

Scored dimensions
Lane visibility, GNSS quality, illumination, agent chaos, road roughness, perception weather; composite ODD 0–100 with per-dimension breakdown
GLARYX heads
lens (dirt/raindrops), glare, atmo (rain, wipers, fog/haze), nightq (ISO grain, motion blur); overallTrust 0–1 via a bound local service
Gating
Lane samples dropped when lens dirt > 0.35 or glare > 0.60; roughness dropped when mount vibration > 0.70; gates recorded per packet
Segmentation
Geohash-7 cell (~150 m) × 8 heading octants, with per-segment Welford statistics and time buckets
Privacy
On-device analysis only; no continuous video stored or sent; evidence thumbnails face- and plate-blurred before writing
Engines
Classical CV by default; optional per-head LiteRT .tflite models via a model registry (GPU → NNAPI → CPU)
Operation
Foreground service, thermal-aware duty cycling, bounded storage, Wi-Fi-only packet upload via WorkManager
Runs on
Android app (Kotlin, Compose, CameraX) built with Gradle and installed via adb
Stack
  • Kotlin
  • Jetpack Compose
  • CameraX
  • LiteRT (TensorFlow Lite)
  • ML Kit face detection
  • Room
  • WorkManager
  • DataStore
  • kotlinx.serialization
  • Play Services Location