RoadSaathi – Smart Pothole Detection & Reporting System

India has one of the largest road networks in the world, yet poor road quality remains a persistent problem. Potholes cause thousands of accidents every year, damage vehicles, and slow down commutes significantly. Traditional reporting methods—helplines, social media posts, nag‑mailing officials—are slow and fragmented.

RoadSaathi aims to turn every commuter’s smartphone into a pothole‑detection device, using the phone’s accelerometer and GPS to crowdsource real‑time road‑quality data. The goal is to build a live, crowdsourced map of potholes that civic authorities can use to prioritize repairs fast and transparently.

Software

1. Mobile App – Flutter with the sensors_plus plugin for accelerometer data.
2. Package: pub.dev/packages/sensors_plus
3. ML Model – TensorFlow Lite for classifying road events (pothole vs. speed bump vs. normal jolt).
4. Framework: www.tensorflow.org/lite
5. Backend & APIs – Node.js with Express or Django (Python) for REST APIs and user management.
6. Express: expressjs.com
7. Database – MongoDB or Firebase Firestore for real‑time pothole logs.
8. Firestore: firebase.google.com/products/firestore
9. Maps & Geolocation – Google Maps API or OpenStreetMap (Leaflet.js) for the pothole heatmap.
10. Google Maps Platform: cloud.google.com/maps-platform
11. Leaflet.js: leafletjs.com
12. Admin Dashboard – React.js with Recharts or Chart.js for analytics.
13. Chart.js: chartjs.org

Hardware

1. Android/iOS smartphone (standard accelerometer + GPS) – no extra hardware needed for basic version.
2. Raspberry Pi (4/3) with an MPU‑6050 6‑axis accelerometer‑gyro module for a dedicated bus‑mounted sensor node.
3. MPU‑6050

In most cities, pothole detection is reactive and manual. A smartphone‑based sensor solution can continuously log road anomalies while people commute, turning every trip into a data point.

RoadSaathi’s idea is simple:

1. Use accelerometer + GPS to detect jolts associated with potholes.
2. Aggregate reports into a central dashboard for municipal/PWD officials.
3. Let the public see which potholes are “In Progress” or “Resolved” for transparency.

The system works in three layers: phone, backend, and dashboard.

1. On the phone:

1. While the app runs (even in background), it reads accelerometer values at regular intervals (e.g., 10–50 Hz).
2. When a sudden spike in vertical acceleration (Z‑axis) exceeds a learned threshold, the app flags a possible pothole event.

2. Data enrichment:

1. Attach GPS coordinates, timestamp, vehicle speed, and a severity score (based on peak acceleration and duration).
2. Optionally, the user can manually upload a photo and description of the pothole.

3. Backend processing:

1. Reports are sent to a server‑side API (Node.js/Django) and stored in a database (MongoDB/Firestore).
2. Historical data for the same road segment is compared to avoid duplicate or false‑positive reports.

4. Authority dashboard:

1. Officials view a heatmap of pothole clusters by locality and can assign repair tickets directly from the dashboard.
2. Monthly analytics show road‑quality trends by ward/zone, helping track improvement over time.

Design the app to be as friction‑less as possible for commuters.

Passive background detection

1. The app continuously listens to accelerometer data without needing user input while driving.
2. Notification or “Do Not Disturb”‑like mode keeps the phone usable while still collecting data.

Manual reporting & photo upload

1. Users can tap a button to mark a pothole, add a short description, and upload an image.
2. This helps authorities validate and search for pothole locations visually.

Live pothole map

1. A simple map view lets users see reported potholes in their city and avoid them pro‑actively.
2. Use Google Maps SDK or Leaflet.js for this view.

Notifications & gamification

1. Users get a push notification when a pothole they reported is marked “Resolved”.
2. Introduce points/badges for frequent reporters to encourage community participation.

The dashboard should focus on actionable insights, not raw data.

Heatmap & clustering

1. Show pothole density by ward/zone using color‑coded heat layers.
2. Cluster reports from multiple users hitting the same spot to increase severity ranking.

Severity ranking

1. Combine frequency of reports and accelerometer impact score to auto‑rank potholes by priority.
2. Higher‑severity clusters appear at the top of the repair queue.

Repair ticket management

1. Officials can create tickets, assign them to field teams, and update status:
2. “Pending” → “In Progress” → “Resolved”.
3. Each status change is logged and visible to the public for accountability.

Analytics reports

1. Generate monthly reports showing:
2. Total potholes reported.
3. Average resolution time per ward.
4. Trend graphs of road‑quality improvement.
5. Use Chart.js or Recharts for embedded charts.

If you want to build your own ML‑based classifier, you can train a model on accelerometer data.

1. Collect training data:

1. Record accelerometer logs manually while driving over known potholes, speed bumps, and normal roads.
2. Use open‑source tools such as GpsAccelerometerRecorder to log raw GPS + accelerometer data.

2. Preprocess signals:

1. Extract short windows (e.g., 1–2 seconds) around detected jolts.
2. Compute features like peak acceleration, RMS, skewness, and kurtosis of the Z‑axis.

3. Train and convert the model:

1. Train a simple classifier (e.g., Random Forest or a small neural network) on these features.
2. Convert the trained model to TensorFlow Lite for deployment on Android/iOS.

4. On‑device inference:

At runtime, the app feeds short accelerometer windows into the TensorFlow Lite model and classifies:

1. “Pothole”
2. “Speed bump”
3. “Normal bump / noise”

To extend coverage beyond smartphones, you can install a Raspberry‑Pi‑based sensor box on public‑transit vehicles or garbage trucks.

1. Connect an MPU‑6050 to the Pi’s I²C bus and read accelerometer + gyro data using Python.
2. Fuse GPS (via USB‑GPS or GNSS module) with the sensor data and send pothole events to the same backend API.
3. Use the this approach for wider, vehicle‑centric road‑quality monitoring across cities.