qazi0/real-time-disaster-management

1. This repository is split into two largely independent ML pipelines under code/: disaster detection/classification and victim localization/object detection. Both are centered on aerial imagery for disaster response, but they use different model families, datasets, and deployment paths.

2. The disaster detection subsystem (code/disaster_detection) is a PyTorch image-classification pipeline built around the AIDER dataset. Its purpose is to classify an input aerial image into one of five emergency-response classes: flood, collapsed building, fire, normal, or traffic incident.

3. The classification training path is: dataloaders/ loads AIDER splits and preprocessing, model/ defines the network variants, train.py trains them, and weights/ stores the trained checkpoints. Supporting training logic lives in training_utils/ for argument parsing, config, metrics, meters, early stopping, and training helpers.

4. The main model boundary in disaster detection is between the two custom architectures: Squeeze ErNET and Squeeze ErNET RedConv. They are improved versions of EmergencyNet-style atrous feature fusion, with shared support code such as acff.py, ernet.py, squeeze_ernet.py, squeeze_ernet_redconv.py, and loss helpers like focal loss and label smoothing.

5. The disaster-detection inference/export path is separate from training. aider-predict.py performs single-image inference, real-time-inference.py runs webcam/stream inference, generate_onnx.py exports ONNX models, and build_tensorrt_model.py converts models into TensorRT-ready artifacts. Prebuilt ONNX files, TensorRT state dicts, and model summaries are checked in to support deployment and comparison.

6. Performance evaluation is also first-class in the classification pipeline. evaluate-classification-metrics.py measures accuracy, F1, and FPS for both PyTorch and TensorRT variants, while calculate-power-usage.py captures power traces on Jetson TX2 and stores plots under power_usage_plots/. This makes the deployment story not just accuracy-driven, but also latency- and energy-driven.

7. The victim localization subsystem (code/victim_localization) is a separate object-detection stack. It focuses on detecting people and vehicles in aerial images using the ODDER dataset and supports multiple YOLO generations: YOLOv3, YOLOv4, and YOLOv5.

8. Within victim localization, the repo contains three parallel model families. yolov3/ and yolov5/ are training/detection codebases with their own configs, datasets, and weights; tensorrt_inference/ wraps optimized inference for YOLO models using TensorRT. Each family has its own runtime and artifact format, so they should be treated as separate deployment targets in an architecture diagram.

9. The YOLO pipelines follow a similar flow: dataset definitions and annotations under data/ or dataset/, model definitions in models/ or config files in cfg/, training via train.py, evaluation via test.py, and inference via detect.py. Pretrained .weights, .pt, ONNX exports, and TensorRT engine files are stored alongside the code to support offline deployment.

10. The TensorRT object-detection path is especially important architecturally. Under victim_localization/tensorrt_inference/, there are CUDA/TensorRT plugin components, calibration caches, ONNX conversion scripts, and a compiled YOLO layer implementation. This indicates a deployment boundary where the YOLO graph is exported, optimized, calibrated, and then executed with GPU-accelerated plugins.

11. Dataset handling is a major boundary in both subsystems. The classification side uses CSV-defined AIDER splits in dataloaders/, while the detection side uses image/label directory layouts and YOLO-formatted text annotations. The repo also includes scripts and files for generating or verifying splits, which are part of the data preparation layer rather than the model layer.

12. Operationally, the repository targets both development and edge deployment. It references Ubuntu x86_64 and NVIDIA Jetson TX2, and includes TensorRT, CUDA, and PyCUDA-related assets where acceleration matters. That means the architecture is not just “train a model”; it is “train, export, optimize, evaluate, and deploy” across CPU/GPU and embedded inference environments.

13. For a diagram, the cleanest high-level separation is: AIDER classification pipeline on one side and ODDER/YOLO victim-localization pipeline on the other, with each pipeline flowing from dataset preparation to training to exported artifacts to optimized inference. Shared concerns like metrics, power analysis, and pretrained artifact storage sit at the edges of both pipelines rather than in the core model logic.