Case Study: Building an Autonomous EV Charging Robot (And What We Learned When We Couldn't)
Case Study: Building an Autonomous EV Charging Robot (And What We Learned When We Couldn't)
Honest lessons from co-founding VoltVogel: simulation-first development, prototype scoping under pressure, and knowing what you actually built
8 min read | Case Study
The Vision
VoltVogel was an autonomous robot that would navigate to electric vehicles and charge them automatically. No cables to plug in, no apps to fiddle with, no dedicated parking spots. The robot comes to the car.
I co-founded VoltVogel with the goal of making EV charging infrastructure more flexible. The use case was fleet charging: rental car companies, corporate fleets, logistics hubs. Places where vehicles sit in large lots and someone has to manually connect dozens of chargers every night. That someone is expensive, unreliable, and doesn't scale.
The technology stack was ROS2-based: autonomous navigation to locate vehicles in the lot, computer vision to identify the charging port, and a manipulation system to connect the charger. We had paying pilots lined up, fleet managers who were genuinely excited about the product, and early funding to prove the concept.
The Reality Check
Here's the part that matters most, and the part most startup case studies skip: the full robot was never built.
Parts were delayed. Supply chain issues hit at the worst possible time. Components we'd specified and ordered were stuck in shipping, with timelines that kept slipping. Meanwhile, we had investors who needed to see progress, customers who needed to see a product, and a runway that didn't care about our supplier's logistics problems.
This is the reality of hardware startups that doesn't show up in pitch decks. Software founders can ship a fix in an afternoon. When your bill of materials is stuck on a container ship, your options are: wait and burn cash, or adapt.
We adapted. But I want to be honest about what that meant. We didn't build the product we set out to build. We built something smaller, more focused, and ultimately more instructive than the original vision.
Most of the autonomy stack, the navigation, the full perception pipeline, the manipulation sequences, was developed and validated in simulation. It worked in simulation. We had confidence in the approach. But simulation confidence and real-world deployment are different things, and we never got to close that gap with the full system.
What We Actually Built
The Works-Like Prototype
With the full robot out of reach, I scoped down to what I called a "works-like" prototype. Not a polished product, not a looks-like demo with smoke and mirrors. A functional system that demonstrated the core value proposition: this robot can charge a real car.
We built it in roughly six weeks. It wasn't fully featured. The navigation was simplified, the manipulation was semi-automated, and the fit and finish was pure engineering prototype. But it connected to real vehicles and charged them. That distinction, between something that looks impressive and something that actually works, turned out to be the most important scoping decision of the project.
The Computer Vision Pipeline
One piece of real, deployed software was the CV pipeline for checking charging status and extracting charging data. This was practical engineering for the prototype stage: given that we couldn't yet automate the full charging sequence reliably, we needed a way to monitor and verify what was happening. The pipeline used camera feeds to determine whether a vehicle was connected, charging, or complete, and extracted the relevant data for reporting.
Simulation-First Development
Since hardware was delayed, I leaned heavily into simulation. The approach was two-tiered:
MuJoCo for rapid iteration and demos. MuJoCo's fast physics and clean rendering made it ideal for quick concept validation and investor demonstrations. When an investor wanted to see the robot in action, we could show a realistic simulation within days of a design change, rather than waiting weeks for hardware iterations.
Gazebo for engineering validation. For the actual robotics development, ROS2-integrated Gazebo simulations provided the engineering-grade fidelity we needed. Sensor models, physics interactions, and ROS2 message flows all matched what the real system would produce, so algorithms developed in Gazebo could transfer to hardware with minimal adaptation.
This dual approach let us develop and validate the full autonomy stack without waiting for hardware that wasn't coming. It's not the same as real-world validation, and I won't pretend it is. But it meant that when hardware did become available, we wouldn't be starting from zero on the software side.
Funding Through Technical Milestones
Despite not having the full robot, we secured over 250,000 euros in funding. That happened because we could demonstrate real technical progress: the working prototype charging actual cars, the simulation pipeline showing the full autonomy concept, and the CV system proving we could extract real data from real vehicles. Technical milestones, when they're honest and well-presented, can substitute for a polished product at the early stages.
Lessons for Hardware Founders
Simulation-First Is Not a Compromise
When I started leaning into simulation, it felt like a fallback. "We can't build the real thing, so we'll simulate it." But I've come to believe simulation-first is actually the right default approach for any robotics startup, even when hardware is available.
The iteration speed difference is enormous. A design change in simulation takes hours. The same change in hardware takes weeks, if you're lucky. The ability to test hundreds of scenarios, failure modes, and edge cases in simulation before committing to hardware saves real money and real time.
The key is being honest with yourself about what simulation proves and what it doesn't. It proves your algorithms work. It proves your architecture handles the state transitions correctly. It doesn't prove your robot won't slip on wet pavement or that your connector can handle the force required to plug into a real charging port. That gap is real, and ignoring it will burn you.
Scope the Prototype, Not the Vision
The most important decision I made at VoltVogel was choosing to build a works-like prototype instead of trying to build a scaled-down version of the full product. These are different things.
A scaled-down product tries to do everything, just less well. A works-like prototype does one thing, the core value proposition, and does it for real. Our prototype charged real cars. It didn't navigate autonomously, it didn't look pretty, and it wouldn't survive a trade show. But it proved the thing that mattered: the fundamental value proposition works.
When you're talking to investors and customers, there's a hierarchy of evidence. "It works in simulation" is good. "It works on a real car" is much better. Even if the rest of the system isn't there yet, that one real-world proof point anchors everything else.
Know What You Built
This is the hardest lesson. After months of intense work, the temptation is to frame everything as a success. We built the prototype. We secured funding. We had customers.
All of that is true. And it's also true that we never built the full robot. The autonomy stack was simulation-only. The company's trajectory didn't follow the plan. Being honest about what you built, and what you didn't, is important. Not just ethically, but practically: if you inflate what you've achieved, you'll make decisions based on false confidence, and those decisions will eventually catch up with you.
What I'd Do Differently
If I were starting VoltVogel again today, three things would change.
First, I'd start with a structured robotics feasibility study before committing to the full system design. Not a quick sketch on a whiteboard, but a proper technical assessment of what's feasible with available components, realistic timelines, and honest risk identification. We underestimated the supply chain risk because we didn't systematically evaluate it.
Second, I'd define the technical MVP more rigorously from day one. The distinction between "works-like prototype" and "full product" should be made explicitly at the start, not discovered under pressure when parts don't arrive. Knowing what your MVP actually needs to prove, and what it doesn't, saves months of misdirected effort.
Third, I'd separate the fundraising narrative from the engineering reality more carefully. We were building for investors and building for engineering validation simultaneously, and those are different activities with different requirements. A fractional CTO who's been through hardware fundraising can help founders navigate that tension without losing technical integrity.
VoltVogel taught me more about building hardware products than any success story could have. The simulation workflows, the prototype scoping, the honest assessment of what works and what doesn't, those are skills I use every day in my advisory work. Sometimes the most valuable case study is the one where you're honest about the gap between the vision and the reality.
