Streamlit web app for live detection of personal protective equipment (PPE). Built on top of a REST API made using FastAPI that provides CRUD operations for fine-tuning any YOLO model designated for object detection, real-time PPE detection, and user management.
Streamlit - For building the web app.
FastAPI - For building the API.
pydantic - For sending and validating requests to the API endpoints.
ultralytics - For accessing and fine-tuning YOLO models.
OpenCV - For live streaming and displaying PPE detections.
PostgreSQL - Database for storing user and fine-tuning data.
SQLAlchemy - For ORM and database interactions.
pytest - For unit and integration testing.
Docker - For containerization.
✅ Enables fine-tuning of all YOLO models designated for object detection from ultralytics.
✅ PPE detection in live video feed using any fine-tuned YOLO model.
✅ Streamlit web app for user-friendly interaction.
✅ User authentication with OAuth2 password flow.
✅ CRUD operations for fine-tuning and user management.
✅ Token-based authentication for API security.
✅ Dockerized for easy deployment.
Multiple experiments were conducted to fine-tune 2 different YOLO models (YOLOv8n and YOLOv10n) on the SH17 dataset with different combinations of hyperparameters. Due to limited computational resources, the experiments were run on a single NVIDIA GeForce GTX 1650 GPU with 4GB VRAM. YOLOv8n and YOLOv10n were chosen for their lightweight architecture and good performance on small datasets. Results of one of the experiments have been summarized below:
| YOLOv8n | |||||||
| Hyperparameters (Expt.: yolov8n_1) | |||||||
| Epochs | Batch Size | lr0 (Initial Learning Rate) | lr1 (Final Learning Rate) | Patience (Early Stopping) | imgsz (Image Size) | Batch Size | Optimizer |
| 30 | 16 | 0.01 | 0.01 | 5 | 640 | 16 | auto |
| Analysis of Plots | ||||
| Plot | Significance | Ideal Trend | Observed Trend | Conclusion |
| train/box_loss - Bounding Box Regression Loss on Training Set | Measures how well the predicted boxes align with the ground truth boxes. | Steadily decreases, suggests that IOU is increasing. | Steady decrease observed. Started at ~1.3, decreased to ~0.9 by the end. | Model is learning to localize objects more accurately with each epoch. |
| train/cls_loss - Classification Loss on Training Set | Measures how well the model predicts the correct object class. | Steadily decreases, suggests that classification accuracy is improving. | Steady decrease observed. Started at ~2.3, decreased to ~0.6 by the end. | Model is learning to distinguish between object types. |
| train/dfl_loss - Distribution Focus Loss on Training Set | Measures how well the model predicts the bins of bounding box coordinates, thus refining bounding box regression. | Steadily decreases, suggests that the model is learning to predict coordinate bins more accurately. | Steady decrease observed. Started at ~1.3, decreased to ~1.09 by the end. | Model is improving its ability to predict bounding box coordinates. |
| val/box_loss - Bounding Box Regression Loss on Validation Set | Same as train/box_loss, but on the validation set. | Steadily decreases, suggests that the model is generalizing well to unseen data, following train/box_loss. | Steady decrease observed. Started at ~1.2, decreased to ~1.03 by the end. | Model is not overfitting, generalizing well to unseen data. |
| val/cls_loss - Classification Loss on Validation Set | Same as train/cls_loss, but on the validation set. | Steadily decreases, suggests that classification accuracy is improving on unseen data, following train/cls_loss. | Steady decrease observed, started at ~1.4 decreased to ~0.7 by the end. | Model is learning to classify objects correctly even on unseen data. |
| val/dfl_loss - Distribution Focus Loss on Validation Set | Same as train/dfl_loss, but on the validation set. | Steadily decreases, suggests that the model is learning to predict coordinate bins more accurately on unseen data, following train/dfl_loss. | Steady decrease observed, started at ~1.3, decreased to ~1.1 by the end. | Model is improving its ability to predict bounding box coordinates on unseen data. |
| metrics/precision(B) - Precision on Validation Set | Measures the proportion of true positive detections out of all positive (true and false positives) detections. In other words, out of all predicted objects, how many were actually correct. | Steadily increases, suggests that the model is becoming more precise in its predictions. | Started at ~0.76, dropped to ~0.47, then unsteadily increased to ~0.6 | Model is adapting to the dataset, largely improving its precision, would need more epochs to stabilize. |
| metrics/recall(B) - Recall on Validation Set | Measures the proportion of true positive detections out of all actual positive objects (true positives and false negatives). In other words, out of all actual objects, how many were correctly detected. | Steadily increases, suggests that the model is becoming better at detecting true objects. | Steady increase observed, started at ~0.23, then increased to ~0.48. | Model is getting better at detecting relevant objects that are actually present in the images. |
| metrics/mAP50(B) - Mean Average Precision at IoU=0.5 on Validation Set | Measures the average precision across all classes at an IoU threshold of 0.5. | Steadily increases, suggests that the model is improving its overall detection quality. | Steady increase observed, started at ~0.25, then increased to ~0.5. | Model is improving its overall detection performance, would need more epochs to stabilize. |
| metrics/mAP50-95(B) - Mean Average Precision at IoU=0.5-0.95 on Validation Set | Measures the average precision across all classes at IoU thresholds from 0.5 to 0.95. | Steadily increases, suggests that the model is improving its overall detection quality across multiple IoU thresholds. | Steady increase observed, started at ~0.15, then increased to ~0.3. | Model is improving its overall detection performance across multiple IoU thresholds, would need more epochs to stabilize. |
Despite the noticeable fluctuations in precision, the general trend of the metrics is positive, which is further supported by the trends in losses, especially the steady decrease in validation losses. This indicates that the model is learning and improving its performance over time, even if it is not yet fully stabilized. The model is adapting to the dataset, and with more epochs, it is expected to further improve its performance and stabilize the metrics. For a lightweight model like YOLOv8n, this is a good result, especially considering the limited computational resources available. This can be set as a basline for further experiments with different hyperparameters or larger models like YOLOv10n, YOLO11n, etc. which can be expected to yield better results.
1. Clone the repository -
git clone https://github.com/F1894125/p4_ppe_detection.git
cd p4_ppe_detection
2. Download the SH17 dataset -
Download the SH17 dataset for PPE Detection from here.
Create a subdirectory named sh17 inside p4_ppe_detection/p4_datasets and extract the contents of the downloaded dataset into this directory.
3. Download and edit the dataset configuration file -
Move inside the p4_ppe_detection/p4_datasets/sh17 directory and curl the dataset configuration file:
curl https://raw.githubusercontent.com/ahmadmughees/SH17dataset/kaggle/sh17_kaggle.yaml -o dataset_config.yaml
Edit dataset_config.yaml as follows:
- Set
pathtop4_datasets/sh17 - Set
traintotrain_files_paths.txt - Set
valtoval_files_paths.txt
Then save the file.
4. Build the Docker images and containers -
Move back to the root directory of the project (p4_ppe_detection) and run:
docker compose up --build
This will build the API, Streamlit, and PostgreSQL containers in a shared network.
Once the containers are up and running, they will be accessible at:
- API container:
localhost:8000 - App container:
localhost:8501
The API docs can be explored at:
localhost:8000/docs(For Swagger UI - recommended)localhost:8000/redoc(For ReDoc)
First, create a user through the Create a User. Then, log in by providing the user email in the username field and the password in the password field. After successful logic, all the other features will be available.
N.B. PPE detection will only work if the containers are built on a Linux system, as containers cannot access the host's webcam directly in Windows or MacOS. To use the app on Windows or MacOS, a stream transfer system needs to be implemented to send the live video feed inside the API container. Upon doing so, the logic for live detection will have to be modified to use the frames received from the stream instead of the webcam feed. Alternatively, you can use a virual machine with a Linux distro to run the app.
⬆️ Add a logging system to save potentially hazardous detections such as hands (indicating no gloves) or faces (indicating no mask).
⬆️ Implement a stream transfer system to send the live video feed inside the API container, since containers cannot access the host's webcam directly.
⬆️ Fine-tune the YOLO models on a more diverse and larger dataset to detect more PPE items with improved performance.
⬆️ Add an alerting system to notify users when PPE is not detected in the live feed and for critical situations.
⬆️ Implement a CI/CD pipeline(GitHub Actions/Jenkins) for automated re-training of models, cloud deployment, and testing.
⬆️ Add more test cases to improve the robustness of the app.
From the keyboard of Angsh, with a lot of head and heart.
If you found this project helpful, consider giving it a ⭐ on GitHub and sharing your thoughts! If you have ideas for a new project, I'm open to collaborate! Feel free to reach out to me on LinkedIn.