Spark began with a simple question: what if a trip could be revisited as a place instead of a folder of disconnected videos? Our four-person team built a privacy-focused system that turns video, spatial sensor data, speech, and detected objects into explorable, searchable 3D memories. My responsibility was the part that had to move through the real world: I led the rover’s mechanical design, embedded control, electrical integration, fabrication, assembly, and physical validation.
We built the complete prototype during the roughly 24-hour SummerHacks 2026 sprint. The result won first place in the SummerHacks Main Track and second place in the TECHNATION Data Intelligence Track among approximately 150 hackers.
The system, not just the robot
The rover was Spark’s physical data-acquisition platform. A phone mounted above the chassis recorded video while providing AR, LiDAR, GPS, and camera metadata. The software pipeline then combined 3D Gaussian splatting, local speech transcription, and object detection so a user could revisit a trip spatially, search for an object, or find the moment when a topic was discussed.
That division of work mattered. Jack Le led the reconstruction and core software; Saivenkat Jilla optimized object detection and built front-end elements; Aman Shah designed the end-to-end product journey and interface. I owned the rover and the electromechanical path from CAD to a moving, capture-ready prototype. The project only worked when those layers met.
What I owned
- Mechanical architecture and CAD in Onshape, including the chassis, pivoting steering geometry, servo cradle, phone holder, and custom wheel adapters.
- ESP32 control architecture and firmware for propulsion and steering.
- Electrical integration of the speed controller, two 540 brushed DC motors, MG995 steering servo, power distribution, and temporary prototype wiring.
- FDM fabrication, fit checks, assembly, soldering, and repeated physical revisions.
- System validation across mechanical, electrical, embedded, and capture-quality constraints.
Designing for a reconstruction pipeline
The rover was not merely a remote-controlled base with a camera attached. Its mechanical behaviour affected the quality of the data delivered to the reconstruction system. Chassis vibration, steering transients, phone rigidity, and motion blur could all reduce the consistency of the video sequence. That turned capture quality into a mechatronics requirement.
I therefore treated the phone mount and running gear as part of the sensing chain. I revised wheel spacing, steering leverage, actuator placement, structural rigidity, and weight distribution while checking whether the rover could move predictably without shaking the capture device. The goal was not maximum speed; it was stable, useful motion from a platform we could build within one night.
Rapid CAD and fabrication under a hard deadline
Almost none of the project’s constraints were negotiable: the parts had to be locally available, the mechanisms had to print quickly, and every revision consumed a meaningful fraction of the remaining event. I designed the structural components around commercially available motors, wheels, fasteners, and electronics, keeping the total rover hardware near $150.
The Toronto Public Library next to the venue became part of the production workflow. I sent prints, checked fit, revised geometry, and returned with corrected parts. That loop forced deliberate simplification. Features that were hard to print, align, or service were liabilities, even if they looked elegant in CAD.
Controls and electrical integration
An ESP32 coordinated steering and propulsion. The electronic speed controller drove the pair of 540 brushed motors, while the MG995 servo actuated the front steering mechanism. I wrote and tested the embedded control path, soldered and routed the power and signal connections, and debugged issues where the apparent symptom could originate in firmware, power delivery, mechanical binding, or wiring.
This was the most valuable systems lesson of the sprint: cross-domain failures do not respect ownership boundaries. A steering response that looked like a software problem could be leverage or geometry. An intermittent reset could be supply stability or wiring strain. Resolving those failures quickly required treating the rover as one coupled system rather than a collection of parts.
Why this work is research-relevant
Spark exposed a useful connection between robot state estimation and scene reconstruction. The current prototype relies primarily on phone-derived spatial data. A future rover can contribute wheel odometry, steering state, commanded velocity, and inertial measurements as additional motion priors. Fusing those signals with visual pose estimates could make capture more robust in texture-poor scenes or during abrupt motion.
That is the direction I want to investigate further: co-designing the physical platform, sensing stack, and reconstruction pipeline instead of optimizing each independently. The rover made the trade-offs tangible. Better geometry and motion control improve the measurements; better pose estimation changes what motion the robot can tolerate.
Outcome
By the end of the sprint, Spark was not a slide deck. We had a complete rover, a local reconstruction and search pipeline, an interactive product flow, and a coherent demonstration connecting them. The judges recognized that integration with first place overall and second place in TECHNATION’s Data Intelligence Track.
The strongest evidence for me was the build itself: under a 24-hour constraint, I moved from requirements to CAD, fabrication, embedded control, electrical integration, and physical validation, then delivered a platform that made the team’s perception software demonstrable.
View Spark on Devpost · Explore the team repository on GitHub