Trash-E: Autonomous Underwater Trash Remediation Robot
An autonomous underwater debris collection robot built on an RC floating platform with a crane-line mechanism and depth-camera-assisted perception.
The problem
Underwater trash is hard to detect, localize, and collect. Visibility is poor. The platform needs to be stable enough to maneuver precisely while carrying a retrieval mechanism. And everything has to work in real water, not just in the lab.
What we built
Trash-E is an RC floating platform with a crane-line collection mechanism and a depth camera for underwater perception. The goal: detect trash-like objects underwater, localize them, and retrieve them with the physical crane mechanism — reliably enough to survive a live demo in real water.
Real-water testing at Jericho. The ocean does not care about your test plan.
The scoping lessons
This project taught me more about project scoping and stack decisions than any course lecture could.
We started, like every ambitious robotics team, by reaching for ROS. It’s the “correct” tool, and I was very confident about this. Step one was figuring out whether we wanted ROS or ROS2, which are related the way a parent and their estranged adult child are related. Step two was picking a distribution - Noetic? Foxy? Humble? - each married to a specific Ubuntu version, none of which I had. So I finally did the thing I’d been putting off for years and dual-booted my PC into Linux, and felt like a Real Engineer™ for approximately one evening.
This was also before ChatGPT went mainstream, so there was no chatbot to gently explain my build errors to me. Debugging meant spelunking through decade-old ROS Answers threads where the accepted solution was “nevermind, fixed it” with no elaboration. I got humbled. Repeatedly. By a middleware.
After weeks of this, we admitted the obvious: the learning curve was consuming time we didn’t have, for capabilities we didn’t actually need. Dropping ROS for a simpler, more direct architecture felt like a defeat at the time. In hindsight it was the single best engineering decision we made. Choosing a stack isn’t about what’s most powerful; it’s about what your team can actually ship within the timeline.
Then came the hardware. Component decisions, components fighting back, and the unglamorous grind of actually sourcing parts on a student budget and a competition deadline. This is where my time at UBC UAS turned out to be critical - I had already fought similar battles with comparable tech there, and a lot of Trash-E came together by macgyvering that experience onto new problems: repurposing what we could get, adapting what we couldn’t, and knowing which corners were safe to cut.
Recognition
The project won the CSME 2025 National Design Competition and multiple awards at the 2024 Canada Tech Futures Challenge, and was featured by MindFuel.ca as part of their recognition of innovative student engineering work.
Here’s the pitch video we made for MindFuel:
The final poster presented at UBC Design and Innovation Day 2024
Looking back
Tensions ran high at points - deadlines, broken hardware, communication. But yet this is a project I look back on quite fondly. Every time I run into the team now, we end up laughing about things that gave us nightmares during testing: the mechanism jamming at the worst moment, the frantic beach-side fixes, the stack decisions we argued over. The struggles became the funny stories, and honestly, those are the parts I miss the most. That’s the quiet lesson of hardware projects: the pain is temporary, but it’s exactly what makes them memorable.