Our UI
Detection Examples

The Inspiration

Living in Turkey, we watch the Mediterranean basin burn almost every summer. The breaking point for us wasn’t just the environmental devastation—which severely threatens native wildlife like our local fireflies (hence the name FireflAI)—but watching how emergency responders operate. They were forced to manually cross-reference weather reports, static satellite hotspots, and radio calls just to figure out where a fire was moving. We realized that time spent reconciling data is time not spent fighting the fire. We wanted to build a single pane of glass: a system that predicts the risk, detects the spark via drone, maps the spread, and autonomously dispatches the trucks.

How We Built It

We designed FireflAI around a decoupled architecture consisting of four core engines: Predict, Detect, Spread, and Dispatch. We didn't want to rely on generic off-the-shelf APIs for the most critical part: the eyes of the system. We manually curated a custom dataset of over 3,600 images and trained a YOLO model from scratch. For the vision pipeline, we relied heavily on OpenCV (via opencv-python-headless). OpenCV handles the heavy lifting of reading live asynchronous drone streams, transforming matrix colors, and rendering bounding boxes directly on edge hardware.

Once OpenCV confirms a threat, the coordinates are sent to our AWS backend (Amazon RDS with PostgreSQL/PostGIS). This instantly triggers our fine-tuned Transformer model to forecast the fire's spread polygon. Finally, an Amazon Bedrock LLM acts as the tactical commander, matching the fire's path against available firefighting resources to generate a concrete deployment plan.

Challenges We Ran Into

The "Sunset" Problem: Early on, our vision model kept classifying beautiful sunsets and autumn leaves as massive wildfires. We had to completely rebuild our dataset using a strict "Hard Negatives" strategy to teach the model visual camouflage.

Agentic Loop Latency: Bridging the gap between OpenCV edge perception and AWS Bedrock cloud reasoning without losing precious seconds was a massive headache. We had to decouple the vision and reasoning pipelines so that the edge device only sends pure metadata to the cloud.

Spatial Hallucinations in the LLM: Getting an LLM to output a strict tactical dispatch without hallucinating locations was tough. We solved this by using a Retrieval-Augmented Generation (RAG) approach, calculating the exact spatial distance between the fire perimeter and nearby critical assets (hospitals, water sources, settlements) using the Haversine formula before prompting the model:$$d = 2r \cdot \arcsin\left(\sqrt{\sin^2\left(\frac{\Delta\phi}{2}\right) + \cos(\phi_1)\cos(\phi_2)\sin^2\left(\frac{\Delta\lambda}{2}\right)}\right)$$

Accomplishments That We're Proud Of

We are incredibly proud of successfully building a true "Agentic Vision" workflow. In FireflAI, a visual frame analyzed by OpenCV actively changes a subsequent tool call and physically redirects a fire truck via an LLM. It is no longer just a dashboard that a human clicks; it’s an autonomous loop.

What We Learned

We learned that data curation is 90% of computer vision. We also learned how to use strict parameter guards (like greedy decoding) to force an LLM to behave like a deterministic military commander rather than a creative chatbot. Above all, we learned how to deeply integrate OpenCV's edge processing capabilities with robust AWS cloud infrastructure.