-
-
The assembled EcoSort chute, with dedicated bins for each material stream.
-
Live dashboard showing paper vs. plastic totals and estimated carbon avoided, updated in real time as items are sorted.
-
The ESP32 controller wired to the ultrasonic sensor and servo on the breadboard.
-
Top view of the sorting chute entry, where the ultrasonic sensor detects incoming items.
-
EcoSort mid-test, sorting an item into its bin.
-
The system log records every sort with material type, weight impact, and timestamp from the ultrasonic sensor.
Inspiration
Recycling only works if the right materials end up in the right bins, and in practice, that sorting step usually fails at the household or public-bin level. We wanted to see if we could take that decision out of people's hands entirely — a physical chute that sorts waste itself, paired with a dashboard that makes the environmental impact visible in real time, rather than something you have to imagine.
What it does
EcoSort is a mechanical sorting chute that uses an ultrasonic sensor to detect when an item drops in, and a servo-driven flipper gate to direct it into the correct bin. Every successful sort sends a live update to a web dashboard, which tracks items sorted by category, running totals, and an estimated carbon-saved figure calculated from a per-material lookup table.
How we built it
The hardware side runs on an ESP32, chosen for its built-in Wi-Fi, allowing it to communicate directly with our cloud backend. An ultrasonic sensor detects when an item enters the chute, while a servo motor controls the physical sorting gate. An Arduino Uno is also used as a power source for the servo. LEDs and a buzzer provide visual and audio feedback during the sorting process.
The software side uses a MERN stack — Express and MongoDB Atlas on the backend, with React on the frontend — deployed to Railway. This allows the ESP32 to send sorting data to the online dashboard rather than relying on a local network.
That last point mattered more than we expected: we built this as a two-person team across two countries (Philippines and Pakistan), so "local network testing" was never an option. We deployed the backend first, before either sensor logic or dashboard styling, specifically so hardware development could happen against a real, live endpoint from day one instead of everyone waiting on each other.
The dashboard went through several iterations — our first version looked like a generic IoT template, so we rebuilt it around the actual physical metaphor of the project: two fill-level bins representing the paper and plastic streams, sized proportionally to real item counts, instead of a generic chart.
Challenges we ran into
The biggest challenge was true material classification. An ultrasonic sensor can detect when an object enters the chute, but it cannot determine whether the material is plastic or paper on its own. Our original concept was to use an AI camera for automatic classification, but we didn't have the necessary resources and computer-vision experience to implement that reliably for this prototype. Rather than oversell the capability, we used a simple manual classification system: the ultrasonic sensor detects the incoming item, then Button A selects paper and Button B selects plastic. The ESP32 then controls the servo-driven flipper gate to direct the item into the selected bin. This allowed us to keep the mechanical sorting and connected dashboard fully functional while leaving computer-vision classification as a future improvement.
We also had challenges with the physical structure of the prototype. We needed a way to build a stable chute, sorting mechanism, and two-bin structure while still being able to modify and test the design quickly. We ended up using LEGO for the physical structure because it allowed us to prototype, adjust dimensions, and rebuild parts of the mechanism much faster than making a permanent structure from scratch.
On the software side, keeping the carbon-saved calculation server-side (rather than sent from the ESP32) took a deliberate decision early on, so the formula could be adjusted without touching firmware. We also hit a handful of real bugs along the way — a stuck chart tooltip, a scroll container clipping the last row of the activity log — that took a few passes to track down and fix properly.
Working async across a 3-hour time zone gap also meant we couldn't debug side by side. We relied on the ESP32 logging every POST attempt and response locally, and the backend exposing a simple way to see incoming data, so either of us could self-verify without the other being online.
What we learned
Building EcoSort needed a lot of planning, but we learned that even a two-person team working from different countries can still create a meaningful working prototype. Even though we had only recently met through Discord, we were able to divide the work, communicate remotely, and build something that addresses a real-world problem.
What's next for EcoSort
We plan to implement camera-based detection, which was part of our original concept, so EcoSort can automatically identify waste instead of relying on manual input. We also want to add a weight sensor for actual weight measurements, support more waste categories with different sorting mechanisms, and replace the LEGO structure with sturdier materials for a more realistic final product.
Built With
- esp32
- express.js
- mongodb
- react
- sensor
- servo-motor
- ultrasonics

Log in or sign up for Devpost to join the conversation.