Skip to content

Status Report

To: Prof. Dr. Christian Baun
Course: Cloud Computing (SS2026)
Team: Team 3 — SentriPi
Date: 21 June 2026

Below is the current status of each task, our approach, and the lead member.

Task 1: Infrastructure Setup

  • Approach: Set up a Raspberry Pi cluster where 8 Pi 3 nodes boot over LAN via PXE instead of individual SD cards. The Pi 5 serves as the central server providing DHCP, TFTP, and NFS services. A static IP was assigned to the Pi 5 on the cluster network, and dnsmasq was configured to assign IP addresses and serve boot files. The OS root filesystem was prepared on the server and exported through NFS so the Pi 3 nodes load their system directly from the network. This centralizes OS image management — updates are applied once and propagated to all workers on reboot.
  • Status: Completed — PXE boot infrastructure designed and deployed. Network configured with static IPs, DHCP reservations, TFTP boot files, NFS root mounting, SSH access, and hostname management for all 8 worker nodes.
  • Lead: Zeeshan Bashir
  • Tools / Technologies: dnsmasq, NFS, TFTP, PXE, Raspberry Pi OS

Task 2: LINPACK Performance (GFLOPS)

  • Approach: Re-imaged the Pi 3 workers with a 64-bit kernel to match the Pi 5's architecture, creating a homogeneous ARM64 environment across all nodes. Compiled HPL LINPACK binaries for the unified 64-bit platform and evaluated raw GFLOPS performance across the cluster.
  • Status: Completed
  • Lead: Hamza Asaad
  • Tools / Technologies: HPL LINPACK, OpenMPI, PXE, NFS

Task 3: MPI Scalability & Amdahl/Gustafson

  • Approach: Configured Pi 5 as OpenMPI launcher and 8 Pi 3 workers as homogeneous compute nodes over the shared PXE/NFS rootfs. OpenMPI and dev tools installed on master and worker environment, passwordless SSH configured, hostfile exposing 4 MPI slots per Pi 3 (32 ranks total). MPI apps compiled on master for Pi 3 architecture, validated with 32-rank hello-world, then evaluated via strong- and weak-scaling benchmarks. Each config uses a warm-up run followed by 7 measured repetitions; median runtime gives speedup, efficiency, and Amdahl/Gustafson scaling. An artificial serial loop is hardcoded into tasks to produce a measurable fixed serial component.
  • Status: In progress
  • Lead: Danish Ali
  • Tools / Technologies: OpenMPI, PXE, NFS, Python

Task 4: Non-MPI Amdahl/Gustafson (Task Distributor)

  • Approach: Configured the Pi 5 as the master node and the 8 PXE-booted Pi 3 workers as compute nodes sharing a common NFS root filesystem. Task Distributor was installed on the master, and its worker script with required libraries was added to the shared worker rootfs. A common NFS workspace was mounted on both master and workers for scene files, lockfiles, and rendered output. Passwordless SSH was configured to launch worker jobs remotely. Benchmarks were run with 1, 2, 4, and 8 workers using fixed and scaled image sizes to demonstrate Amdahl's Law and Gustafson's Law. Runtimes were recorded in CSV files and analyzed with Python to calculate speedup, efficiency, throughput, and generate result charts.
  • Status: Completed — benchmarks executed, speedup curves generated, laws validated.
  • Lead: Danish Ali
  • Tools / Technologies: Task Distributor, Python, NFS, SSH

Task 5: Cluster Monitoring & Infrastructure Telemetry

  • Approach: Designed an end-to-end telemetry system to track cluster vitals — CPU load, RAM utilization, core temperatures, and disk capacity. Deployed native Node Exporter binaries across all 10 cluster nodes (Pi 5 master, Pi 4 sensor node, and 8 Pi 3 workers). Configured a containerized Prometheus instance on the Pi 5 operating in network_mode: host to scrape performance metrics every 15 seconds. Integrated a Grafana instance with the Prometheus data source using the standard Node Exporter Full dashboard (ID 1860) for real-time visualization.
  • Status: Completed — dashboards live and scraping all nodes. Regression testing after MPI integration remaining.
  • Lead: Muhammad Hamza Laghari
  • Tools / Technologies: Prometheus, Grafana, Node Exporter, Docker

Task 6: Object Detection Model Training

Due to the scope, this task was divided across multiple team members.

6a — Dataset Collection & Preparation

  • Approach: Collected a custom dataset of ~1,500–3,000 balanced images per class (fire, smoke, knife) instead of using a pre-trained model. Knife data sourced from Roboflow Universe with CCTV-angle preference. Hard negatives (pens, wires, cutlery) captured on the Pi 4 camera with empty labels to suppress false positives.
  • Status: Completed — custom dataset collected and labelled.
  • Lead: Akshit Sandeep Bane
  • Tools / Technologies: Roboflow, Raspberry Pi Camera

6b — Model Fine-Tuning & NPU Deployment

  • Approach: Fine-tuned a pretrained YOLO11n backbone on Kaggle (Python 3.10, GPU) rather than training from scratch. The resulting .pt was exported via Sony MCT with INT8 quantization to packerOut.zip, then packaged into network.rpk for on-device IMX500 NPU inference at 30 fps.
  • Status: Completed — model fine-tuned, quantized, and deployed to IMX500.
  • Lead: Sahil Qasim Khan
  • Tools / Technologies: YOLO11n, Sony MCT, Kaggle, IMX500

Task 7: Backend Development

Due to the scope, this task was divided across multiple team members.

7a — Application Communication Architecture

  • Approach: Designed the system architecture detailing communication flow between the sensor node, backend, distributed storage, and frontend. The architecture employs REST for event ingestion and polling, SeaweedFS for distributed image storage, MongoDB for event metadata, and system design diagrams document the complete pipeline.
  • Status: Completed — architecture documented with system design diagrams.
  • Lead: Muhammad Hamza Laghari
  • Tools / Technologies: System architecture design, excalidraw

7b — Sensor Inference & REST API

  • Approach: Built detector.py on the Pi 4 sensor node that loads a custom-trained YOLO11n model onto the IMX500 camera, runs real-time inference, and upon detecting a threat class (fire, smoke, weapon, person, mask) above the confidence threshold, captures the frame with bounding boxes and POSTs the event to the Pi 5 backend. On the Pi 5 server side, two FastAPI endpoints handle ingestion and retrieval: POST /events decodes the base64 snapshot to disk and stores metadata in MongoDB, while GET /events serves paginated event records (sorted newest-first) for the frontend polling interface.
  • Status: Completed — inference and API endpoints operational and tested.
  • Lead: Abdul Rehman
  • Tools / Technologies: YOLO11n, IMX500, FastAPI, MongoDB, OpenCV, Python, Docker

7c — Distributed Storage Implementation

  • Approach: Implemented distributed volume-based object storage using SeaweedFS. Deployed containerized SeaweedFS Master and Filer daemons on the Pi 5 using host networking. The 8 PXE-booted Pi 3 workers run automated weed volume engines mounting their local MicroSD partitions (/dev/mmcblk0p2 to /mnt/sdcard). The SeaweedFS Master aggregates these 8 physical targets into a shared pool of 48 volume slots (1024 MB per block) with lazy allocation, exposed via a transparent FUSE mount at /data/images on the Pi 5.
  • Status: Completed — implementation and data sharding verified. Offline for validation testing following hardware maintenance and MPI integration.
  • Lead: Muhammad Hamza Laghari
  • Tools / Technologies: SeaweedFS, FUSE, MongoDB, Docker, Python

Task 8: Frontend Development

  • Approach: React 18 + TypeScript + Vite frontend with FastAPI backend, both Docker containerized. Eight frontend pages: Dashboard (cluster health), Sensor Nodes (per-node live metrics), Cluster Monitoring (aggregate/per-node Prometheus metrics), Object Detection (paginated event feed with live camera and snapshots), Storage (SeaweedFS/MongoDB stats), Performance (HPL/MPI/Amdahl/Gustafson results from Steps 2–4), Containers (Docker container + node state), and Notifications (Telegram-style chat log). State via Zustand, REST via fetch. Backend exposes POST /events, GET /events, GET /metrics/nodes, GET /storage, GET /services. Docker Compose orchestrates mongo + api + frontend services with volume mounts for database and images.
  • Status: Completed — React scaffold with all pages and Zustand stores, backend API integrated end-to-end, production Nginx/Docker frontend container deployed alongside the backend on the Pi 5 master (edge-frontend, restart: unless-stopped).
  • Lead: Muhammad Hamza Bilal Baig
  • Tools / Technologies: React, TypeScript, Vite, FastAPI, Docker, Zustand

Task 9: Telegram Bot Notifications

  • Approach: Telegram bot registered via BotFather pushes alerts on threat detections (threat class, confidence, snapshot) and infrastructure events (node down, high CPU/temperature) from Prometheus. Backend handles webhook/long-poll integration. Frontend Notifications page displays a chat log of bot messages.
  • Status: Completed — backend triggers real Telegram alerts on high-threat detections and node up/down transitions, with per-rule cooldowns and MongoDB-backed alert rules (toggleable from the frontend). Frontend Notifications page shows the real message log and rule state, no longer seed data.
  • Lead: Muhammad Hamza Bilal Baig
  • Tools / Technologies: Telegram Bot API, Python, FastAPI

Task 10: Documentation & Presentation

  • Approach: Create reproduction-oriented online documentation using MkDocs with the Material theme, published via GitHub Pages. The site covers step-by-step setup for each task, architecture diagrams, benchmark results, and known pitfalls. A poster and live demonstration will be presented at the closing event.
  • Status: In progress — MkDocs site initialized with status report, task skeletons, architecture diagrams, and automated CI/CD deployment. Task content being drafted collaboratively.
  • Lead: Muhammad Hamza Laghari
  • Tools / Technologies: MkDocs, Material for MkDocs, GitHub Pages, Markdown