During testing, SafeEdge's first detector flagged a simulated fire on a screen. A second model recognised that it was not a fire in the room and stopped the alert.

Five of eight frames must agree

We built SafeEdge's fire-detection prototype in 24 hours. Classical vision and YOLO watched each frame for smoke and fire. A detection had to appear in five of eight recent frames before it moved to the next check. That keeps a single bad frame from triggering this path.

The first pass runs locally in a 6MB model. YOLO finds fire-like objects while optical flow watches for haze.

The screen-fire test passed this check with 0.69 confidence. It needed another check before sending people down an evacuation route.

SafeEdge then blurs any faces and sends the frame to a second vision model. That model checks whether to send an alert.

SafeEdge detecting a possible fire in a camera frame
The local detector marking a possible fire in the camera feed.

Checking the scene before sending an alert

SafeEdge second vision pass rejecting a false positive
The second model stopped a candidate alert before it reached the command centre.

For confirmed alerts, SafeEdge calculates routes around the hazard to one of nine NTU assembly zones. The command centre shows the alert's location and the evacuation routes together.

Taking the demo to Changi Fire Station

After the hackathon, I took the demo to Changi Fire Station to get feedback from a firefighter. The conversation moved from detecting a fire to the paperwork after an incident.

Three problems came up. Photos did not always cover what was needed for the report. Drawing an incident map meant arranging shapes by hand. Details such as the location and call time were already recorded elsewhere, but still had to be entered again.

I used that feedback to plan HeatBlast, a separate report-drafting proposal for the SCDF and Dell challenge. It would check photo coverage, fill in incident details already on record and prepare a draft for an officer to review.