Lunar Rover
A lunar rover prototype built at RoboHacks at Y Combinator to collect regolith in a moon-surface scenario, with a four-node autonomous control architecture spanning remote viewing, ground control, satellite relay, and robot control.
Problem
RoboHacks at Y Combinator was framed as the first robotics hackathon at the YC office: one weekend to build applications on general-purpose robots across manipulation, navigation, and interaction. The event ran April 11-12, 2026 in San Francisco, bringing together 120 builders using 25 MARS robots.
Our team used that setting to build a lunar rover project for a moon-surface collection scenario. The project was originally called Per Aspera, but the clearer portfolio name is Lunar Rover. The concept was a rover that could pick up regolith from the dark side of the moon, while separating the human-facing interface from the autonomy and low-level robot control.
Team: Aathavan Senthilkumar, Jacob Valdez, Pranesh Kumar, and Samuel Liu.
Solution
The lunar rover split the system into four autonomous control nodes:
- Remote viewer: a human-facing interface for observing the robot and mission state.
- Ground control: the planning and supervisory layer.
- Satellite relay: an intermediate communications node that imitates the constraints of off-world robotics.
- Robot control: the node responsible for the rover itself.
The point was not just to drive a robot around a table. We wanted the prototype to feel closer to a real lunar robotics setup, where commands, perception, routing, and actuation are mediated through a mission architecture instead of being collapsed into one direct controller.
Rover demo clip from the project thread.
How
The project combined a rover build, mission-control software, and autonomous route planning. The public post described the core setup as a four-node control system built to imitate a more realistic remote robotics stack, plus autonomous LLM route planning.
The important design move was architectural: each node had a different job, so the rover could be discussed as a distributed robotic system rather than a single script controlling motors. That made it easier to reason about what should be visible to a remote operator, what should be planned by ground control, what should pass through the relay, and what should happen locally on the robot.
Tests
The hackathon test was an integrated demo: can the rover, interface, and autonomy stack behave like one mission system under time pressure?
We validated the build through physical rover operation, video-recorded demos, and the project presentation materials. The tests were pragmatic rather than lab-grade: assemble the robot, run the route-planning and control flow, show the rover moving through the intended scenario, and make the system explainable to judges and other builders.
Second rover demo clip from the archived thread media.
Results
Lunar Rover became a complete weekend prototype: a rover concept, physical build, mission architecture, autonomous route-planning story, demo media, and project presentation.
The result was useful because it made a hard robotics idea legible quickly. A viewer could understand the rover's mission, the distributed control stack, and the reason for using a remote-viewer / ground-control / satellite / robot-control split without needing to inspect every implementation detail.
Lessons
For robotics hackathons, architecture is part of the demo. A rover that moves is interesting; a rover that moves as one node in a believable mission system is much easier to explain as a serious autonomy project.
The project also showed the value of turning LLM planning into a bounded subsystem. Route planning belongs inside a larger control architecture with clear interfaces and failure boundaries, especially when the story is remote robotics rather than a local toy demo.