AWS Builder Center

Builder Center

Building DilliJalNav Edge: How We Fused On-Device Computer Vision with AWS Serverless to Conquer Delhi's Monsoon Floods

How we built an edge-to-cloud urban flood navigation system using PathFinder AR (WebGPU), Amazon Bedrock (Claude 3.5 Haiku), and DynamoDB Single-Table TTL to protect 210M Indian two-wheelers and delivery fleets from submerged underpasses and hidden potholes.

When Delhi’s Roads Flood, Your GPS Needs More Than a Red Line: Building DilliJalNav Edge with AWS

Author: Pranav Pant Team: Kernel Event: Bharat Builds Tour — Event 02: Environmental Hacks Organizers: WeMakeDevs × AWS Track: Track 02 — Heat and Water Source code license: MIT-0


When a Road Looks Open but Isn’t Safe

If you have travelled through Delhi during the monsoon, you know how quickly an ordinary commute can turn into a problem. Heavy rain can leave underpasses waterlogged, slow traffic across nearby roads, and make familiar routes difficult to judge. For two-wheeler riders, even a puddle can hide a pothole or an uneven road surface.
Navigation apps are useful for understanding traffic and finding routes. But a red line on a map does not explain whether vehicles are moving slowly because of congestion or because the road ahead is flooded.
That distinction became the starting point for DilliJalNav Edge, our project for the Bharat Builds Tour hackathon at Delhi Technological University (DTU).
We set out to explore a practical question: Can on-device computer vision and AWS serverless services help commuters identify road hazards and make better routing decisions?
DilliJalNav Edge combines a mobile-facing hazard-detection interface with a cloud backend for collecting reports, evaluating available evidence, and sharing hazard information with the navigation layer. The goal is to complement existing navigation services—not to claim that a prototype can already detect every flooded road or guarantee a safe journey.

1. Why Traffic Data Isn’t Enough

Imagine an underpass during heavy rainfall. Water begins accumulating, vehicles slow down, some drivers turn back, and traffic builds up behind them. A navigation application may detect the slowdown and show congestion, but that information does not necessarily explain the cause.
A flooded road and a busy road are different problems. The first may require avoiding the segment altogether.
The same gap appears with other hazards:
  • Water-filled potholes: Murky water can conceal damaged road surfaces and make their depth difficult to judge.
  • Unmarked speed breakers: Poor visibility and faded markings can make raised sections hard to spot.
  • Open construction sites: Excavations, damaged covers, and exposed road sections can create unexpected obstacles.
  • Fallen trees and storm debris: Heavy rain and strong winds can leave branches or other objects across a road.
These hazards may not be reflected in traffic data immediately, especially when the first affected vehicle encounters them. Computer vision offers another source of information: the visible condition of the road itself.
It also has limitations. Rain, reflections, darkness, camera angle, and poor visibility can affect detection. A camera cannot reliably infer the depth of every puddle from a single frame. We therefore treat visual detection as evidence to be evaluated—not as a guarantee that a road is safe or unsafe.

2. Introducing DilliJalNav Edge

The system is organised around three connected components:
  1. PathFinder AR: A mobile-facing interface for camera-based hazard detection and rider warnings.
  1. AWS serverless backend: A system for receiving telemetry, processing reports, and maintaining hazard records.
  1. Hazard-aware navigation: A routing layer that can use a validated alternative waypoint to avoid a reported problem area.
The edge component focuses on local awareness. The cloud component provides a shared view of reports from different sources.
Keeping vision processing on the device reduces the need to transmit continuous camera footage. Instead, the backend can receive compact reports containing the relevant detection, location, timestamp, and supporting information.
This separation also means that local detection may continue when connectivity is unavailable, even though cloud-based reporting and route updates would depend on a network connection.

3. Architecture: From the Camera to AWS

The following diagram describes the intended flow through the system.


Horizon 1: On-device detection with PathFinder AR

PathFinder AR is the mobile interface through which a rider can receive information about potential hazards.
The proposed vision pipeline uses a quantized YOLOv8n model with ONNX Runtime Web. WebGPU may accelerate inference on supported devices; a suitable fallback is needed where it is unavailable.
The pipeline is designed to:
  1. Capture a frame from the device camera.
  1. Run object detection locally.
  1. Identify potential hazards supported by the model.
  1. Display a warning when a relevant detection is made.
  1. Provide an audio alert where appropriate.
  1. Send a compact telemetry report when connectivity is available.
A warning could say: “Savdhaan! Aage paani bhara hai.” The intention is to give the rider a clear signal without asking them to type a report while moving.
The interface can also explore visual cues such as kerb visibility and the apparent extent of standing water. These cues are not equivalent to a reliable measurement of water depth. A partially obscured kerb may indicate standing water, but actual depth depends on road geometry, camera position, and the visibility of reference points. Reliable depth estimation would need calibration and validation against real measurements.

Keeping camera processing local

Uploading every camera frame would increase network usage and introduce additional latency. Our architecture keeps the vision pipeline on the device and sends only the information needed by the backend.
A short rolling evidence buffer could also retain footage locally for later review, subject to browser storage limits, permissions, and retention rules. Such a feature needs careful implementation: local storage is not a guarantee that footage will survive a crash, remain available indefinitely, or never be transmitted.
The guiding principle is to collect and retain only the data needed for the feature, with clear controls over access and deletion.

Horizon 2: AWS serverless processing

The cloud component gives the application a shared view of reported hazards. Each service has a distinct role:
  • Amazon API Gateway provides the HTTP entry point for telemetry submissions.
  • AWS Lambda validates incoming reports, applies evaluation logic, and coordinates updates.
  • Amazon DynamoDB stores hazard records, timestamps, locations, and current status.
  • Amazon EventBridge can schedule periodic jobs, such as checking external rainfall information.
  • Amazon Bedrock can help extract structured information from natural-language reports, including Hindi and Hinglish messages.
Rainfall information could come from an appropriate external provider, subject to data availability, geographic coverage, update frequency, and access conditions. Rainfall is useful context, but it does not prove that a particular underpass is flooded.

Horizon 3: Hazard-aware navigation

When a hazard is considered credible, the navigation layer needs to decide how to respond. One option is to use a configured alternative waypoint to route around a known problem area.
For example, if an underpass is reported as unsafe and a suitable elevated corridor is available, the client could request a route through a waypoint on that corridor.
This avoids having to rebuild the underlying road network for every temporary report. But a waypoint does not automatically make a route safe. The resulting path must be checked against the road network, access restrictions, other known hazards, and the destination. If no suitable alternative can be validated, the system should not present an unverified detour as safe.

4. Engineering Challenge One: Understanding Hinglish Hazard Reports

People rarely describe road conditions in formal language. A commuter might say:
“Bhai, underpass ke neeche 3 foot paani bhara hai. Aage bus phasi hui hai, bike toh bilkul mat bhejna.”
Or:
“Paani silencer tak chadh gaya, gaadi band ho gayi.”
These messages may contain the location, a possible hazard, severity, affected vehicle types, and a suggested action. Extracting this information into a predictable structure is more useful to a backend than forwarding the original message.
We explored using Amazon Bedrock for structured extraction from natural-language reports. A possible schema could include:
  •  hazard_detected : Whether the report describes a potential hazard.
  •  location_id : The associated location, if it can be established.
  •  estimated_depth_inches : A reported or independently estimated depth, if available.
  •  restricted_vehicles : Vehicle types that may be affected.
  •  suggested_action : The action described by the report.
  •  confidence_score : A measure associated with the extraction.
The important distinction is that extracted information is not necessarily verified information. If a speaker says the water is three feet deep, a model may correctly extract that number without independently measuring the water. Similarly, confidence in interpreting a message is not the same as the probability that the report is genuine.
The backend should validate the output against a schema, handle missing or ambiguous fields, and distinguish reported facts from uncertain inferences. A production implementation would also need error handling for malformed output, timeouts, retries, and unsupported locations.
Structured extraction makes a report easier to process. Verification determines whether it should influence navigation.

5. Engineering Challenge Two: Keeping Hazard Reports Fresh

Collecting reports is only half the problem. The system must also keep them accurate as conditions change.
Imagine an underpass reported as flooded at 10:00 a.m. The water drains later, but the record remains active. If the navigation interface continues to avoid the road, commuters may take unnecessary detours.
We considered two separate mechanisms for managing a hazard’s lifecycle.

Explicit clearance

The backend can evaluate new evidence suggesting that a hazard has cleared. Repeated observations from vehicles passing through a monitored segment might indicate that traffic is moving normally again.
However, normal speed is not proof of safety. Vehicles may be using another lane, bypassing the hazard, or passing through conditions that remain dangerous for other road users. A clearance decision should consider location, observation quality, hazard type, and corroborating evidence.
When the available evidence is sufficient, the backend can update the hazard status and notify the navigation interface.

DynamoDB TTL for record cleanup

Amazon DynamoDB supports Time to Live (TTL), which allows an item to carry an expiration timestamp. For example:
Python
import time

expires_at = int(time.time()) + 2700  # 45 minutes
The value  2700  represents 45 minutes in seconds.
There is an important limitation: DynamoDB TTL deletes expired items asynchronously. It is a cleanup mechanism, not a timer that guarantees deletion exactly 45 minutes later. The application must check whether a hazard has expired before using it to influence a route, and it needs a separate process for clearing hazards when sufficient evidence becomes available.
An expired record and a confirmed-clear road are not necessarily the same thing. A record can become stale while the road remains flooded, or the road can become passable long before the item is deleted. Separating hazard status from record retention makes the system easier to reason about and safer to operate.

6. Engineering Challenge Three: Routing Around a Hazard

Some routing engines use preprocessing techniques such as Contraction Hierarchies to speed up route calculations. How they handle temporary road closures depends on the engine and its configuration.
Rather than rebuilding the road graph every time a hazard appears, we explored routing through a suitable, preconfigured waypoint.
Let:
  • (S) be the starting point.
  • (W) be a candidate bypass waypoint.
  • (D) be the destination.
  • (d(A,B)) be the route distance between two points.
The routing objective can be expressed as:
P* = arg min [d(S, W) + d(W, D)]
Here, (\mathcal{P}) represents the routes available through the routing engine. This expresses the idea of routing through a waypoint; it does not guarantee that the resulting route is safe.
The engine still needs to find valid paths to and from the waypoint. The route must then be checked against known hazards and applicable road restrictions. A waypoint can simplify integration between hazard reporting and navigation, but it cannot replace route validation.

7. Engineering Challenge Four: Battery Life and Thermal Limits

Running a camera and neural network continuously can place a significant load on a mobile device. For a rider who relies on a phone throughout the day, excessive battery use or thermal throttling would make the application impractical.
We considered several ways to reduce unnecessary inference.
Location-aware activation: The application could increase monitoring near known waterlogging hotspots. GPS readings are imperfect, however, and a dangerous road can exist outside a known hotspot. Location should guide resource use, not be treated as proof that a road is safe.
Frame-rate control: Processing every camera frame may not be necessary. A lower inference rate, such as 10 frames per second, could reduce computational load while still allowing frequent visual checks. The right rate depends on the model, device hardware, lighting, camera position, and detection distance. Any claim about reduced temperature or battery use should be backed by tests on representative devices.
Keeping video off the cloud: Local inference reduces the need to upload footage continuously. Only compact telemetry needs to be transmitted, reducing network usage and avoiding a cloud request for every frame. Local warnings may still be possible without connectivity, while shared hazard updates and remote routing would require a connection.
These trade-offs show why mobile performance is part of the architecture, not an optimisation to leave until the end.

8. Combining Evidence Instead of Trusting One Signal

A crowdsourced system must account for mistakes, outdated reports, and deliberate misuse. A single voice report should not automatically close a road, and heavy rainfall should not automatically mark every nearby underpass as flooded.
Our proposed consensus model combines several signals:
  • (E): Confidence from the on-device vision detector.
  • (R): A normalised rainfall signal.
  • (V): Evidence of abnormal traffic speed.
  • (B): Confidence in extracting information from a natural-language report.
  • (H): Historical hazard risk associated with the location.
A possible weighted score is:
S_consensus = 0.30E + 0.25R + 0.20V + 0.15B + 0.10H
A threshold could determine whether a report should be escalated for further verification. The weights and threshold are design parameters, not established safety guarantees. They must be evaluated against labelled observations before being used for real-world routing decisions.
The signals are not necessarily independent. Rainfall and traffic slowdown can occur together without a road being flooded. A language model can accurately extract a false report, and a vision model can repeatedly misclassify the same reflection.
A stronger implementation would also consider duplicate reports, location accuracy, source reliability, timestamps, and how quickly evidence becomes stale. Both false positives and false negatives matter: unnecessary detours frustrate users, while incorrectly declaring a dangerous road safe can have much more serious consequences.
The consensus model should support verification, not replace it.

9. Lessons from the AWS Architecture

Working through the architecture highlighted three engineering lessons.

Design DynamoDB around access patterns

DynamoDB data modelling starts with the queries an application needs. For this project, those might include retrieving active hazards in a geographic area, checking the current status of a hotspot, and looking up an individual report.
Partition keys, sort keys, and secondary indexes should be chosen to support those operations. Repeated table scans may be acceptable for a small experiment, but they are not a substitute for targeted queries in a frequently accessed system.
TTL can help remove old records; it does not determine whether a road is safe.

Treat model output as untrusted input

A language model can make informal reports easier to process, but its output still needs validation. The backend should enforce a defined schema, handle missing fields, and distinguish reported information from inferred information.
Latency and cost should be measured using the actual model, request size, invocation pattern, and deployment configuration. A successful test call does not establish that the full pipeline will meet a particular latency target.

Make infrastructure reproducible

Manually creating cloud resources can be convenient during an early experiment, but it becomes harder to reproduce the environment as a project grows. AWS Serverless Application Model (AWS SAM) can define serverless resources in configuration files.
Combined with version control and suitable local testing tools, infrastructure as code makes deployments easier to reproduce and review. It also encourages more deliberate handling of permissions, configuration, and environment-specific settings.

10. Why We Explored a Serverless Design

Waterlogging-related activity can vary with the weather. A monitoring application might receive relatively little traffic during ordinary conditions and experience a surge of reports during heavy rainfall.
An event-driven architecture is worth exploring for this kind of workload. AWS Lambda can process events without requiring the team to manage application servers directly. API Gateway provides a managed HTTP entry point, while DynamoDB stores hazard information and supports targeted queries. EventBridge can schedule periodic checks, and Amazon Bedrock can support natural-language extraction where needed.
Serverless does not remove the need for capacity planning or cost management. A sudden increase in requests can still expose concurrency limits, downstream bottlenecks, retries, and database hot partitions. Before a real-world deployment, the system would need realistic load testing, monitoring, appropriate service limits, and a clear strategy for handling failures.
For a hackathon project, serverless services offer a practical way to explore the cloud architecture without first operating a dedicated fleet of servers.

11. Running the Project Locally

The intended development workflow uses the AWS SAM CLI for the backend and a local development server for the frontend. The commands below assume the repository contains the required configuration and dependencies.
Start LocalStack, if the project uses it to emulate the AWS services it depends on:
Bash
localstack start -d
From the backend directory, build and start the API:
Bash
cd backend
sam build
sam local start-api --port 3001
In another terminal, start the frontend:
Bash
cd frontend
npm install
npm run dev
The backend must be configured to use the appropriate local service endpoints where needed, and the frontend must point to the correct backend URL. These commands should be checked against the repository’s current README before publication; the workflow will only work if the corresponding configuration and dependencies are present.
If the repository includes a hazard simulation, it can be used to submit a sample report and inspect how the application responds.

12. What Comes Next?

Before considering a real-world pilot, we would prioritise several areas:
  • Validate the vision model: Measure detection performance across lighting conditions, camera angles, road surfaces, and rainfall intensities.
  • Improve depth estimation: Compare visual estimates against ground-truth measurements and communicate uncertainty clearly.
  • Measure false positives and false negatives: Test the consensus model against labelled reports and real observations.
  • Strengthen hazard clearance: Distinguish between normal traffic and evidence that a road has actually become safe.
  • Test on real devices: Measure battery consumption, thermal behaviour, inference latency, and camera compatibility over extended journeys.
  • Validate alternative routes: Check proposed detours against the road network, other reported hazards, and applicable restrictions.
  • Improve privacy and security: Establish camera permissions, data-retention rules, access controls, and safeguards against fraudulent submissions.
These are not minor finishing touches. They determine whether a navigation system can be trusted with decisions that affect physical safety.

Conclusion: Better Information About the Road Ahead

DilliJalNav Edge started with a problem Delhi commuters know well: a road that looks acceptable on a map may be unsafe on the ground.
We explored an architecture that combines on-device computer vision with AWS serverless services to address part of that gap. PathFinder AR provides the mobile-facing detection and warning experience. The cloud backend can collect telemetry, process natural-language reports, and maintain hazard records. The navigation layer can then use validated alternative waypoints to avoid reported problem areas.
The difficult part is not simply detecting water or sending a report to the cloud. It is deciding how much confidence to place in the information, keeping records accurate as conditions change, and avoiding recommendations that create a different risk.
There is still work to do on model validation, route safety, mobile performance, and real-world testing. DilliJalNav Edge is a step toward more hazard-aware navigation, not a claim that every flooded road can already be detected or avoided automatically.
For our team, the project was an opportunity to explore how edge computing and AWS services could be combined to address a problem close to home.
A safer journey starts with better information about the road ahead.
Built by Team Kernel for the Bharat Builds Tour — Environmental Hacks.
# artificial-intelligence# amazon-bedrock# amazon-dynamodb# serverless# computer-vision
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article