AQUASCOUT Get the APK
Back to site Figure 1 of 1 · plain-language version

System architecture

AQUASCOUT: what leaves the phone, and what does not

The device boundary is the design. Camera frames are analysed inside it and stop there. Only a label, a confidence and a position cross. The rover is an optional response unit, not a requirement for the alert to fire.

AQUASCOUT system architecture The camera feeds a YOLOv8n model inside the device boundary. From the model, a label and confidence go to the alert log, a label and GPS position go out by SMS to the emergency contact, and D-pad commands go to an optional rover. Camera frames stop at the boundary and never reach either cloud service. ON DEVICE LEAVES THE DEVICE OPTIONAL FIELD UNIT FRAME LABEL + SCORE LABEL + GPS SMS, 30S DEBOUNCE D-PAD OVER BLE FRAMES STOP HERE INPUT Camera 2.0 fps, 640x640 MODEL YOLOv8n dynamic INT8 3.2 MB, fire + smoke mAP50 0.748 CLOUD Alert log Firebase, if signed in no frames stored ALERT SMS Semaphore API optional, off by default ACTOR Emergency contact one number, any carrier no app needed IN PROGRESS LAFVIN 2WD rover 2 driven wheels + front caster Arduino UNO, JDY-16 BLE, HC-SR04 2 ESP32-CAM + water pump RESPONSE UNIT STATUS Parts acquired and specified. Not wired: the motor driver failed and awaits replacement, so no actuation is claimed. The alert path works without it. LEGEND network call optional, not finished blocked at the boundary focal, the thesis
AQUASCOUT · build 1.56 mAP50 0.748 on the 4,306-image D-Fire test split · 2.0 fps on a mid-range Android device