Segregation Score — AI-Powered Community Waste Audit Platform**
Segregation Score is an AI-powered platform designed to help hostels, housing societies, and communities improve waste-management practices through computer vision. Users can upload images of waste and select a waste stream: wet, dry, sanitary, or special. The platform explores image analysis and object detection to identify visible waste items such as plastic bottles, cans, wrappers, paper, and other litter.
I Had No NVIDIA GPU, 4,784 Waste Annotations, and a Deadline. Here's How I Built Segregation Score.
An Environment Hacks story about building an AI waste-auditing prototype, debugging AWS, training YOLO on a CPU, and learning why a model that runs isn't necessarily a model that works.
There is a particular kind of confidence you have when starting a hackathon project.
You have an idea. You have a tech stack in mind. You can already imagine the final demo.
Then reality shows up.
Your AWS credentials stop working. Your dataset needs more preparation than expected. Your laptop has no NVIDIA GPU. And the model you've spent hours training starts identifying a glass bottle as a paper bag.
Suddenly, the roadmap looks very different.
That was my experience building Segregation Score for Environment Hacks.
The project started with a simple question:
What if computer vision could help communities understand and improve their waste segregation practices?
I didn't want to build another sustainability dashboard that looked impressive in a presentation but offered little practical value. I wanted to explore a workflow where someone could upload a picture of waste, identify what's visible, and eventually use that information to make community waste audits more useful.
The idea was straightforward. Making it work was not.
1. The problem I wanted to solve
Waste segregation is easy to talk about and surprisingly difficult to monitor consistently.
Hostels, housing societies, and residential communities generate different types of waste every day. Checking whether that waste is being separated correctly can involve manual inspections, inconsistent records, and a lot of guesswork.
I started thinking about whether image analysis could help.
Imagine uploading a photograph of discarded waste and receiving information about the objects present. Over time, those observations could potentially help a community understand recurring waste patterns and identify where better segregation practices are needed.
That became the vision for Segregation Score.
The initial workflow was simple:
- Upload a waste image.
- Select a waste stream.
- Analyze the image.
- Display the result.
- Assess whether there is enough evidence to support a waste-category decision.
I organized the interface around four streams: wet, dry, sanitary, and special waste.
But there was one technical question I needed to answer before building anything more ambitious:
Could I reliably identify waste objects in real-world images?
That question would end up shaping the entire project.
2. Building the application before solving the AI problem
I started with Next.js, TypeScript, and Tailwind CSS.
The frontend handled image uploads, previews, file validation, and waste-stream selection. I also built a backend API so the image-analysis process could happen separately from the interface.
For the first recognition approach, I integrated Amazon Rekognition.
It gave me a way to analyze images and retrieve labels for visible objects and scenes. However, I quickly realized that general-purpose image recognition wasn't quite the same as the waste-detection experience I wanted.
There's a difference between identifying that an image contains a bottle and locating the bottle with a bounding box while assigning it a meaningful object category.
That distinction led me to explore object detection.
Before I could get there, though, I had to deal with a more familiar developer problem: the backend wasn't always cooperating.
AWS credentials and account verification created obstacles during integration. The frontend could accept an image perfectly well while the backend failed to analyze it.
Installing an SDK was only one part of the process. Authentication, permissions, configuration, and the actual service request all had to work together.
It was a useful reminder that an application isn't functional just because its interface looks finished.
3. Discovering TACO: the dataset that changed the direction
To move beyond general image labels, I explored TACO — Trash Annotations in Context.
TACO provides real-world litter images with annotations identifying waste objects and their locations. That made it a suitable starting point for experimenting with object detection.
My annotation file contained:
- 1,500 images
- 4,784 annotated objects
- 60 waste categories
This was the turning point. Instead of relying entirely on general-purpose image recognition, I could train a detector using waste-specific annotations.
But downloading a dataset and preparing it for training are two very different things.
TACO uses COCO-style annotations, while YOLO expects a different format. I needed to convert the annotations, map category IDs, generate normalized bounding-box coordinates, organize the images, and create separate training and validation sets.
I also checked whether the images referenced by the annotation file actually existed on disk. All 1,500 referenced images were present.
Then I found another issue: seven bounding boxes extended beyond the image boundaries.
I handled these during conversion by clipping the boxes to the image boundaries and skipping any boxes that remained invalid, while leaving the original annotations untouched.
After preparing the dataset, I had:
- 1,200 training images
- 300 validation images
- 60 original categories
It wasn't the most glamorous part of the project, but it was essential.
A model can't learn properly from a dataset that hasn't been prepared and checked carefully. Before worrying about model performance, I needed to make sure the training pipeline had valid data to work with.
4. No NVIDIA GPU. So, CPU it was.
Here's where my hardware situation got interesting.
I was working on Windows with Python 3.10 and an Intel Core i7-13620H. I didn't have an NVIDIA GPU.
I could have spent a large part of the hackathon trying to configure hardware that wasn't available on my machine. Instead, I decided to get the pipeline working on the CPU first.
I installed CPU-compatible builds of PyTorch and TorchVision, set up Ultralytics, and tested a pretrained YOLO26n model on a sample image.
It detected four people and one bus, with approximately 152 milliseconds of model inference time on my CPU.
That wasn't a waste-detection result, of course. It was a baseline test to confirm that the environment and inference pipeline were working.
Still, it was an important milestone.
The model loaded. Inference ran. Bounding boxes appeared.
For the first time, I had a working starting point for the object-detection part of the project.
The next step was to see whether that pipeline could learn something useful from waste-specific data.
5. Training completed. Then the real test began.
With the dataset prepared, I fine-tuned YOLO26n for three epochs.
I knew that three epochs on a relatively small, imbalanced dataset wouldn't be enough to establish production-level performance. My immediate goal was more modest: complete the training run, generate a checkpoint, and test it against waste images.
The training completed successfully.
I tested the checkpoint on a TACO image, and the model predicted a paper bag and an object classified as an other-plastic-wrapper category.
For a moment, seeing waste-related labels appear on the screen felt like progress toward the finish line.
Then I checked the validation metrics.
The results told a different story.
At the end of training, the model's overall validation metrics were approximately:
Metric | Result |
|---|---|
Precision | 29.6% |
Recall | 2.38% |
mAP@50 | 1.59% |
mAP@50–95 | 1.40% |
These results were far below what would be needed for a reliable waste detector.
The per-category results were concerning, too. For example, plastic film had approximately 8.1% precision and 3.4% recall. Other plastic wrappers also performed poorly, while several categories produced results close to zero.
The dataset's class distribution added another challenge. Cigarette litter had hundreds of annotations, while several other categories had fewer than ten.
I had successfully trained a model, but I had not built a reliable detector.
That distinction became one of the most important lessons of the entire project.
A successful training run doesn't prove that a model performs well. A bounding box appearing on a screen doesn't mean the object has been correctly identified. And a demo that looks convincing isn't necessarily a system that works reliably in the real world.
The checkpoint was a useful engineering milestone, not a finished solution.
6. Testing the models against reality
Rather than assume the trained YOLO model was good enough, I compared it with Amazon Rekognition using the same images.
I created a separate local test environment so I could experiment without changing the deployed application.
The early results were revealing.
Actual object | YOLO prediction | Rekognition prediction |
|---|---|---|
Plastic bottle | Plastic bottle cap | Bottle |
Paper cup | Plastic bottle cap | Mostly road and city labels |
Red Bull metal can | No detections | Can, alongside unrelated labels |
Glass bottle | Paper bag and | |
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article