← Back to projects

Project Overview · Computer Vision + Cloud

CarbinWatcher

A computer-vision smart trash can that tells you which bin to use — backed by a serverless AWS pipeline designed to grow from our one hackathon prototype to 1,000+ cans.

The problem

Most people sort waste wrong, and one trash can can't scale.

Recycling only works when items land in the right bin, but the rules are confusing and people guess. CarbinWatcher puts a camera on the can: it classifies each item with computer vision (YOLO + OpenCV) and tells the user which bin to use.

The hard part isn't one smart can, it's many. A real deployment means a fleet of cans all streaming images and classifications at once, a dashboard showing them live, and an analytics layer turning the raw stream into environmental impact. That has to hold up whether there's one can or a thousand, which made this an architecture problem as much as an ML one.

Architecture

A serverless streaming pipeline that scales with the fleet.

Each can publishes over MQTT into AWS IoT Core, which fans the data out two ways: a real-time path to the live app, and a durable path for analytics. Because every stage is managed and event-driven, the same design serves one can or a thousand with no servers to babysit.

CarbinWatcher cloud architecture A camera publishes over MQTT to AWS IoT Core. IoT Core streams through Kinesis Data Firehose to Amazon S3 and on to Databricks ML and ETL pipelines feeding an impact dashboard; IoT Core also stores metadata in Amazon DynamoDB, which feeds the live application. AWS Cloud Databricks MQTT stores metadata Camera edge device IoT Core MQTT broker Kinesis Data Firehose Amazon S3 raw store Amazon DynamoDB live classifications ML pipelines ETL pipelines · XGBoost Impact Dashboard Live App React / Next.js
Camera → IoT Core → Kinesis → S3 → Databricks → impact dashboard for analytics; IoT Core → DynamoDB → live React/Next.js app for real-time classifications.

Key decisions

Why it's built this way.

MQTT + IoT Core for the edge

MQTT is the standard for lightweight device messaging, and IoT Core terminates it as a managed broker. Cans stay dumb publishers; the cloud handles fan-out, so adding cans costs nothing architecturally.

Split hot and cold paths

DynamoDB serves the live app with low-latency reads of the latest classifications, while Kinesis → S3 keeps a durable, cheap record for batch analytics. Each path is tuned for its job instead of forcing one store to do both.

S3 → Databricks for analytics

Linking S3 to Databricks let me run scheduled XGBoost jobs over the accumulated stream to estimate environmental impact, without coupling analytics to the real-time serving path.

Serverless-first under a deadline

Every managed, event-driven stage meant no servers to provision during a hackathon, and a design that already scales. The demo ran on the same architecture a fleet would.

What shipped

A working demo, live at DataHacks.

The full loop worked end to end: point the camera at an item, watch the classification appear in the live dashboard within moments, streamed through the real pipeline. Here's the walkthrough.

Challenges & what's next

Honest edges.

Wiring a multi-service AWS pipeline correctly under a hackathon clock, IAM, IoT rules, and the Kinesis → S3 handoff, was the real work; getting the permissions and message routing right took more time than the model. Next would be hardening the fleet story: per-device auth, an on-device model to cut bandwidth, and a proper backfill for the analytics layer.

Stack

  • Python
  • C++
  • OpenCV · YOLO
  • React
  • Next.js
  • AWS IoT Core
  • Kinesis
  • S3
  • DynamoDB
  • Databricks
  • XGBoost
  • MQTT