🌍 Inspiration
Robotics has a frustrating loop: design, buy hardware, build, discover a problem, replace parts, and try again.
As a student, I kept thinking about the waste hidden inside that process. A wrong motor, unsuitable battery, unstable control strategy, or unnecessary component is not just a software mistake once physical hardware has been purchased.
That led to Kodro.
The idea is simple:
What if a robot had to prove itself digitally before it deserved to become physical?
Instead of treating simulation as something you use after choosing your hardware, Kodro makes simulation part of the decision itself.
🤖 What it does
Kodro is a browser-based robotics workspace for moving from an idea to a more defensible physical build.
A user can:
Design a robot and configure its components. Simulate its behaviour before committing to hardware. Test different configurations and expose failures digitally. Compare alternatives before choosing what should actually be built. Prove the selected configuration through EarthProof. Build only after the design has evidence behind it.
The goal is not to claim that simulation eliminates environmental impact.
It is to make better pre-build decisions possible, so developers have an opportunity to catch unnecessary hardware choices and failed configurations before they become physical iterations.
The loop
IDEA
DESIGN
SIMULATE
TEST
EARTHPROOF
BUILD
If something fails, the cheapest place for it to fail should be before the physical build.
🌱 Why EarthProof?
Many sustainability tools begin after something already exists.
EarthProof moves the question earlier:
Should this particular configuration be built at all?
The Earth Forward idea behind Kodro is therefore not a sustainability badge attached to a robotics project. It changes the development workflow itself.
Instead of:
Buy → Build → Test → Fail → Replace
Kodro encourages:
Design → Simulate → Test → Compare → Prove → Build
EarthProof presents evidence from the digital development process so that a user can understand why a configuration is ready, questionable, or worth revisiting.
Where environmental information cannot be measured reliably, Kodro does not invent an impact number. The project deliberately separates reproducible engineering evidence from estimates and assumptions.
💡 What makes Kodro different?
Robot simulators already exist.
Sustainability dashboards already exist.
Kodro's focus is the decision between simulation and physical construction.
EarthProof turns simulation results into a pre-build checkpoint rather than leaving them as disconnected graphs or test outputs.
That means the important question is no longer only:
“Does my robot work?”
It becomes:
“Do I have enough evidence to justify building this version?”
That distinction became the central design principle of the project.
🛠️ How I built it
Kodro was developed as a web-first robotics environment with the workflow designed around rapid experimentation and reproducibility.
The system connects the major stages of the robotics lifecycle rather than treating design, simulation, testing, and evidence as unrelated screens.
A major technical focus was making EarthProof traceable.
The judge-facing flow is intentionally:
Design → Simulate → Prove → Build
The evidence shown at the end comes from the preceding workflow rather than being a decorative sustainability score.
I also built automated verification around the project so important behaviour can be reproduced instead of relying entirely on a prepared demo.
🧠 What I learned
The biggest lesson was that sustainability in engineering is not necessarily another feature.
Sometimes it is a decision constraint.
Initially, it was tempting to represent sustainability through a single score. But a confident-looking number is useless if its assumptions cannot be defended.
Building EarthProof pushed me to think much more carefully about:
reproducibility uncertainty evidence provenance hardware trade-offs simulation reliability responsible environmental claims designing interfaces that explain why, not just what
I also learned that a technically impressive simulation is not enough. Users need to understand how its results affect the next real-world decision.
🚧 Challenges Making sustainability measurable without pretending certainty exists
Environmental impact is complicated.
Different components have different manufacturing histories, lifetimes, supply chains, energy requirements, and disposal pathways. Kodro therefore avoids presenting unsupported environmental savings as scientific fact.
EarthProof focuses on what the system can actually demonstrate and clearly separates that evidence from assumptions.
Connecting simulation to a meaningful decision
It was relatively easy to display simulation output.
The harder problem was answering:
What should the developer do with it?
That challenge produced the EarthProof checkpoint.
Building something understandable in minutes
A hackathon judge should not need a robotics manual to understand the project.
The final experience therefore concentrates on one visible journey:
Design it. Simulate it. Prove it. Then decide whether to build it.
🕒 Project history and hackathon work
Kodro originated before NextStep Hacks as part of my broader work exploring robotics development and simulation.
For NextStep Hacks 2026, I developed the EarthProof direction and hackathon-specific experience around the Earth Forward challenge, including the pre-build proof workflow, its presentation, verification, and judge-facing experience.
I am explicitly preserving this distinction rather than presenting the entire underlying project as work created during the hackathon.
🔭 What's next?
EarthProof can become much more powerful as real, verifiable hardware and lifecycle datasets become available.
Future directions include component lifecycle information, repairability and reuse signals, richer hardware comparisons, physical-device validation, and better modelling of the uncertainty between simulation and reality.
The long-term goal is straightforward:
Make “prove before you build” a normal part of robotics development.
Because the most sustainable unnecessary prototype may be the one that never had to become hardware.
Log in or sign up for Devpost to join the conversation.