PavIQ — Road-Condition Intelligence Case Study | Abhay Kumar
Validated Concept · Pre-Build

PavIQ

A fleet-deployable sensor box that turns everyday buses and taxis into a continuous, city-wide road-condition survey — replacing a $26K–$105K survey run with data that updates every day.

My role
Discovery → technical spec
Status
v0.1 · Pre-build
BOM per unit
CAD $580
Market
$40B+ TAM
The problem

Cities manage roads with almost no real-time data

Condition surveys run once every one to three years, at CAD $26,000–$105,000 per run, or rely entirely on reactive citizen reporting. The consequences compound: emergency pothole repairs cost 3–5× more than planned maintenance, and UK motorists alone lose an estimated CAD $3 billion a year to suspension and tyre damage.

  • Road authorities can't prioritise maintenance spend without objective, network-wide severity data.
  • Navigation apps route without any surface-condition awareness.
  • No affordable, continuously updating, city-scale dataset exists for most municipalities today.
Discovery

A supply side and a demand side

MC

Municipal & council engineer · Buyer

Needs objective, city-wide severity data to justify infrastructure spend and shift from reactive to preventive repair.

FO

Fleet operator · Data partner

Hosts the hardware on vehicles already driving the network daily — the free-fit offer that gets the sensor onto the road before any council contract exists.

Backlog

User stories that shaped the spec

US-01 As a council engineer, I want an objective, city-wide pavement condition index so I can prioritize budget with data instead of complaints. Must
US-02 As a fleet operator, I want the device installed with zero disruption to routes so hosting a sensor costs me nothing operationally. Must
US-03 As a council, I want every defect GPS-tagged and severity-graded so I can auto-dispatch repair crews to the right location. Must
US-04 As a navigation platform, I want a safe-traversal-speed layer per road segment so I can offer a "comfort route" alternative. Should
US-05 As an engineer, I want the device to buffer up to 72h of data offline so temporary LTE gaps never lose readings. Should
US-06 As a fleet manager, I want a private wear-hotspot dashboard so I have a reason to host the hardware before any council contract exists. Could
Requirements

Spec'd as testable acceptance criteria

RequirementPriority
Detect and classify road defects at 200Hz with Minor/Moderate/Severe gradingMust
GPS geo-tag every event, with dead-reckoning bridging GNSS outages in urban canyonsMust
On-device high-pass + Kalman filtering to reject chassis vibration, not just road impactsMust
72-hour offline buffering with automatic batch upload on reconnectMust
Fail-safe clean shutdown on ignition cut to prevent SD-card filesystem corruptionShould
AI speed-recommendation model output per road segment, licensable to nav APIsShould
Predictive deterioration model forecasting when a segment crosses intervention thresholdsCould
My role

From a $40B market claim to a buildable BOM

I sized the market, mapped the client ecosystem (municipalities, nav platforms, insurers, OEMs), and specified the full hardware and data pipeline down to individual component costs — so a technical co-founder could start ordering parts instead of debating architecture.

What I designed

A sensor box, a cloud pipeline, and three ML models

Five-sensor hardware stack

Industrial IMU + dead-reckoning GPS + barometric altimeter + wide-angle camera + 4G LTE, on a Raspberry Pi 4, in an IP65 enclosure. CAD $580 per unit.

On-device signal processing

High-pass + Kalman filtering separates real road events from vehicle body roll before anything is ever recorded.

Cloud aggregation pipeline

AWS IoT Core → PostGIS Postgres, aggregated nightly by OpenStreetMap segment ID to refresh the heatmap.

Three-model AI layer

Pothole classification (MobileNetV2), speed recommendation (XGBoost) — the most commercially differentiated layer — and predictive deterioration modeling.

Under the hood

A bump becomes a graded, mapped event

1Z-axis acceleration sampled at 200Hz; a hit above 0.4g for 20ms triggers an event
2Filtered event graded Minor (.4–.7g) / Moderate (.7–1.2g) / Severe (>1.2g)
3GPS + altitude + a 2-second camera thumbnail attached as ground-truth
4JSON packet uploaded via MQTT — or held up to 72h if LTE is unavailable
5Nightly aggregation by road segment refreshes the city-wide condition heatmap
Outcome

A 20-week path to a government-ready demo

PavIQ is a complete technical spec — hardware, firmware, data pipeline, AI strategy, and a component-level bill of materials — not yet built. The plan gets from bench prototype to a five-unit fleet pilot and government-facing dashboard in 20 weeks for roughly CAD $6,100–$10,300, with a risk register already covering the failure modes (SD-card wear, GPS loss, mounting noise) that typically kill field hardware.

Roadmap

Three phases, 20 weeks

Weeks 1–5

Bench prototype — integrate every sensor, validate a clean simultaneous JSON log.

Weeks 5–10

Vehicle validation — four weeks of daily driving, 200+ labelled events, first Mapbox heatmap.

Weeks 10–20

Fleet pilot — five units on a taxi operator, city-scale data, council-facing demo.

More case studies

See the rest of the work, or get in touch.