RECLAIM: Autonomous Indoor Waste-Sorting Robot

The product integrates five subsystems on a differential-drive platform: 24V E-S planetary gearmotors for locomotion, a 6-DOF arm for pick-and-place, an OAK-D stereo camera with YOLO under TensorRT FP16 for detection across waste classes, a Livox Mid-360 3D LiDAR with SLAM Toolbox + a hybrid coverage algorithm for navigation, and an STM32F405 microcontroller for CAN-bus actuator control. The reduced-scope prototype used lower-cost substitutes, OAK-D Lite, a 4-DOF hobby-servo arm with a LewanSoul claw, YOLO26n (6 classes), Teensy 4.1, and a vision-servo state machine, with an RPLIDAR A1M8 on the prototype, but exercised the full scan→detect→drive→pick→sort loop.

The repository is a five-package ROS2 monorepo: reclaim_perception, reclaim_navigation, reclaim_control, reclaim_bringup, and reclaim_interfaces.

Beyond the software, the product is a full electromechanical design: mechanical CAD, the microcontroller wiring I laid out, and its power distribution. I owned the perception + control electronics and the arm; the chassis CAD is the team's product concept.

Three pick-attempt runs on the physical prototype, captured during capstone testing and on the showcase floor (March 2026). Each exercises the full vision-servo loop: detect → approach → pick → sort. (The navigation re-benchmark above is post-capstone, in simulation.)

Re-benchmarked across 5 venue presets × 3 seeds (15 missions per algorithm), v2 completed every venue, from conference (30 items; seed 7: 1030.6 s, 130.3 m) to expo (70 items; seed 42: 3142 s, 508.4 m, 5 dump trips):

Post-event waste at large indoor venues is a concurrent operational and environmental problem. A single NFL game generates 35–40 tonnes of waste at cleanup costs approaching $46,000, while single-stream recycling contamination rates of 25–30% cost the U.S. recycling industry an estimated $3.5–4 billion annually. Existing automation addresses these problems in isolation: floor scrubbers lack end effectors, stationary sorters like AMP Robotics Cortex require fixed conveyor infrastructure. No commercially available platform integrates autonomous navigation, object-level detection, physical pickup, and multi-stream sorting on a single mobile base.

4-person capstone team (Abdul Kassem, Issa Ahmed, Dev Panara, Shady Siam). I owned the perception + control stack end-to-end: the Jetson Orin NX onboard computer and every Python ROS2 node running on it, the Teensy 4.1 firmware + pinout/wiring for actuators and encoders, the YOLO perception model design and TensorRT export pipeline, and the URDF + servo work for the 4-DOF prototype arm.

YOLO26n trained on a combination of Roboflow + Kaggle waste datasets, refined across three training cycles (v3, v5, v6) using confusion-matrix-driven class elimination to cut the class set from 11 to 6 and drop ambiguous categories. mAP50 improved from 0.693 to 0.826 across those cycles. Exported under TensorRT FP16 to hit 30 FPS on the Jetson Orin NX, sufficient to drive a vision-servo control loop without dropping frames.

The capstone shipped a robot, and a navigation benchmark I stopped trusting. The original simulator assumed an idealized 0.5 m/s robot with continuous motion, and its numbers made it into the final report. After the March showcase I rebuilt the simulator from scratch (reclaim_v2, June 2026), calibrated to the real robot's measured specs: 0.3 m/s max linear velocity, 1.0 rad/s angular, 0.3 m/s² acceleration, 0.470 m wheel separation, the OAK-D's 73° FOV and 0.4–3.0 m detection range, and the ~13 s/item stop-look-drive approach cadence from the real waste_tracker_v2.py pipeline, then re-benchmarked every algorithm on it. Every navigation number on this page comes from that re-baseline. The honest result: the algorithm I presented at the showcase completes 6 of 15 missions on the calibrated simulator. The rewrite completes 15 of 15.

reclaim_v2 is an event-driven executive over four behaviors (SCAN, COLLECT, SWEEP, DUMP) arbitrated by priority:

• Commits, doesn't thrash. The executive re-decides only on events (item picked, scan finished, path blocked) never per-tick, so target switches happen at plan boundaries instead of oscillating between goals.
• SCAN: frontier exploration. Scan viewpoints sit on the seen side of the fog boundary, scored by unseen cells revealed per unit of travel-plus-scan time, with a directed pivot scan on arrival (0.25 rad/s around the left wheel, like the real robot).
• COLLECT: exact routing where it's affordable. Batches of ≤7 items are routed exactly (Held-Karp) over true A* path distances; larger batches use nearest-neighbor + 2-opt. Dump-station stops are inserted at the tour boundary that adds the least detour, computed in closed form from an init-time Dijkstra field.
• Motion + recovery. Pure-pursuit driving with acceleration limits matching the real drivetrain, plus a watchdog recovery ladder: 3 consecutive A* failures requeues the item, 6 abandons and logs it, so one unreachable item can never hang a mission.

The simulator runs entirely client-side: React + Three.js (R3F), with a headless Node harness that regenerates the benchmark matrix from a single command. Every run is reproducible byte-for-byte from its (preset · seed) chip, shown in the UI. Try it live: pick a venue and seed, watch the planned route, behavior timeline, and live detection captions, and pit v2 against the four baselines on the comparison dashboard, interactive 3D demo ↗.

The product arm is a 6-DOF CubeMars BLDC arm with a Robotis parallel gripper driven by MoveIt2 motion planning. MATLAB inverse-dynamics confirmed adequate torque margins across all arm joints with a 500 g payload, and a computed torque controller achieved near-zero tracking error across pick-and-place trajectories. The prototype substituted a 4-DOF hobby-servo arm with PI joint control and a PI tracking controller for vision-servo approach behaviour.

The prototype was demonstrated live, completing fully autonomous scan→detect→drive→pick→sort cycles across all six waste classes with no manual intervention. The cohort awarded the project 3rd place overall, and 1st in the AI division.

The tightest engineering constraint was the gap between the product spec and what we could realistically build in 8 months on an undergraduate budget. The response was to scope two layers: a fully specified product (CubeMars BLDC arm, OAK-D Pro, Livox Mid-360 LiDAR, STM32F405 + CAN, 27+ waste classes, MoveIt2 + Nav2) and a reduced-scope prototype that exercised the same control loop with hobby-grade components. That separation forced honest reasoning about what we were validating with each subsystem and is what carried us through the live demo without manual intervention.

The second constraint was self-imposed, after the grade was in: the navigation benchmark I'd presented was measured on an idealized simulator, and I knew it. Rebuilding the simulator around the real robot's calibrated dynamics (and publishing that the showcase-era algorithm completes 6 of 15 missions on it) cost me the headline number and bought a result I can defend line by line.