AegisGrid
A 48-hour hackathon build that classifies and ranks multi-source aerial threats in real time using DBSCAN spatial clustering, deployed before the closing ceremony.
The Problem
When multiple drones approach from multiple directions, the hard problem isn't detection, it's prioritization. An operator needs to know which cluster of threats matters most, right now.
Research
With 48 hours on the clock, research compressed into the first evening: what clustering approach handles an unknown number of threat groups, arbitrary shapes, and noise points that belong to no group?
K-means fails on all three counts, you must pick k in advance, and stray single drones distort every centroid. DBSCAN handles unknown cluster counts natively and treats isolated points as noise, which maps exactly to how a human operator thinks about a stray drone versus a coordinated swarm.
The Solution
The system ingests multi-source aerial contacts, clusters them spatially with DBSCAN, then scores each cluster on severity and proximity to protected zones, producing a ranked threat list that updates in real time.
A FastAPI backend owns ingestion, clustering, and scoring; a React/TypeScript frontend renders the live tactical picture with cluster boundaries and priority ordering, deployed on Vercel.
- DBSCAN clustering over live threat positions
- Severity × proximity scoring per cluster, ranked continuously
- FastAPI intelligence layer + React/TypeScript live dashboard
Technical Decisions
DBSCAN over k-means for threat grouping
The number of threat clusters is unknowable in advance, and noise-point handling gives 'lone drone' semantics for free. Density-based clustering matched the domain instead of forcing the domain to match the algorithm.
Ruthless scope-cutting to the intelligence layer
In a 48-hour build, the demo lives or dies on the core loop: ingest → cluster → rank → visualize. Everything else, auth, persistence, replay, was cut on purpose.
Trade-off: The result is a proof of intelligence, not a product; that was the right trade for a hackathon.
What Didn't Go As Planned
DBSCAN's epsilon parameter made clustering either too eager or too fragmented as threat density changed.
Tuned epsilon against simulated swarm scenarios of varying density during the first night, settling on a value validated across all our demo cases, and documented it as a known static-parameter limitation.
Integrating a live-updating dashboard with a moving backend under time pressure.
Froze the API contract between backend and frontend at hour 12 so both halves could move in parallel without breaking each other.
Outcome
AegisGrid proved I can scope, build, and ship a working intelligent system under a hard deadline with a team, the constraint most engineering actually happens under.
Reflection
A production version needs adaptive epsilon (OPTICS or HDBSCAN) to handle varying threat density, and temporal tracking so clusters have identity across frames instead of being re-derived every tick.