1st Place at SummerHacks: Spark Robotic Rover

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

• Electrical integration of the speed controller, two 540 brushed DC motors, MG995 steering servo, power distribution, and temporary prototype wiring.
• ESP32 control architecture and firmware for propulsion and steering.
• Soldering, power and signal routing, subsystem bring-up, and fault isolation across electronics, firmware, and mechanics.
• Mechanical architecture and CAD in Onshape, including the chassis, servo cradle, a steering linkage I designed from scratch, and custom front and rear wheel adapters.
• FDM fabrication, fit checks, assembly, 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 sensor mounting and running gear as part of the sensing chain. I designed the steering linkage from scratch, choosing the pivot positions, link lengths, and servo connection that translated the MG995’s motion into a predictable wheel angle. I then 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.

Electronics and embedded control

I owned the rover’s electrical and embedded integration: the ESP32 control layer, electronic speed controller, pair of 540 brushed DC motors, MG995 steering servo, power distribution, and prototype signal wiring all had to operate as one system. I wrote and tested the control path for propulsion and steering, soldered and routed the connections, brought up the actuators, and then validated the complete rover under the event’s time pressure.

The difficult work was not simply connecting components. A failed steering response could originate in firmware, servo power, wiring, leverage, or mechanical binding. A propulsion fault could sit anywhere between the ESP32 command path, speed controller, motor connections, or drivetrain. I isolated problems by testing subsystems independently, then re-integrating them until the rover responded predictably.

That cross-domain debugging is the strongest evidence from the build: I could move between power, signals, embedded code, and mechanics without handing the problem off. Under a roughly 24-hour deadline, that systems-level ownership turned a collection of motors, electronics, printed parts, and temporary wiring into a working mobile platform.

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