Fallstudie: Einen autonomen EV-Laderoboter bauen (und was wir gelernt haben, als es nicht klappte)
Fallstudie: Einen autonomen EV-Laderoboter bauen (und was wir lernten, als es nicht klappte)
Ehrliche Lektionen aus der Mitgruendung von VoltVogel: Simulation-First-Entwicklung, Prototyp-Scoping unter Druck und das Wissen, was man wirklich gebaut hat
8 Min. Lesezeit | Fallstudie
Die Vision
VoltVogel war ein autonomer Roboter, der zu Elektrofahrzeugen navigiert und sie automatisch laedt. Kein Kabel einstecken, keine App bedienen, kein reservierter Parkplatz. Der Roboter kommt zum Auto.
Ich habe VoltVogel mitgegruendet mit dem Ziel, EV-Ladeinfrastruktur flexibler zu machen. Der Anwendungsfall war Flottenladung: Mietwagenunternehmen, Firmenfuhrparks, Logistik-Hubs. Orte, an denen Fahrzeuge auf grossen Parkplaetzen stehen und jemand jede Nacht Dutzende Ladegeraete manuell anschliessen muss. Dieser Jemand ist teuer, unzuverlaessig und skaliert nicht.
Der Technologie-Stack basierte auf ROS2: autonome Navigation zur Fahrzeuglokalisierung auf dem Gelaende, Computer Vision zur Identifikation des Ladeanschlusses und ein Manipulationssystem zum Anschliessen des Ladegeraets. Wir hatten zahlende Piloten in der Pipeline, Flottenmanager, die wirklich begeistert waren, und fruehe Finanzierung, um das Konzept zu beweisen.
Der Realitaetscheck
Jetzt kommt der Teil, der am meisten zaehlt, und den die meisten Startup-Fallstudien weglassen: Der volle Roboter wurde nie gebaut.
Teile waren verspaetet. Lieferkettenprobleme trafen zum denkbar schlechtesten Zeitpunkt. Komponenten, die wir spezifiziert und bestellt hatten, steckten im Versand fest, mit Zeitplaenen, die immer weiter rutschten. Gleichzeitig hatten wir Investoren, die Fortschritt sehen mussten, Kunden, die ein Produkt sehen mussten, und eine Runway, der die Logistikprobleme unseres Zulieferers egal waren.
Das ist die Realitaet von Hardware-Startups, die in keinem Pitch Deck auftaucht. Software-Gruender koennen einen Fix am Nachmittag ausliefern. Wenn deine Stueckliste auf einem Containerschiff feststeckt, hast du zwei Optionen: warten und Cash verbrennen, oder dich anpassen.
Wir haben uns angepasst. Aber ich will ehrlich sein, was das bedeutete. Wir haben nicht das Produkt gebaut, das wir uns vorgenommen hatten. Wir haben etwas Kleineres gebaut, fokussierter, und letztlich lehrreicher als die urspruengliche Vision.
Der Grossteil des Autonomie-Stacks, die Navigation, die volle Wahrnehmungspipeline, die Manipulationssequenzen, wurde in Simulation entwickelt und validiert. Es funktionierte in der Simulation. Wir hatten Vertrauen in den Ansatz. Aber Simulationsvertrauen und realer Einsatz sind verschiedene Dinge, und wir kamen nie dazu, diese Luecke mit dem vollen System zu schliessen.
Was wir tatsaechlich gebaut haben
Der Works-Like-Prototyp
Da der volle Roboter ausser Reichweite war, schrumpfte ich den Scope auf das, was ich einen "Works-Like"-Prototyp nannte. Kein poliertes Produkt, keine Looks-Like-Demo mit blossem Blendwerk. Ein funktionales System, das das zentrale Wertversprechen demonstrierte: Dieser Roboter kann ein echtes Auto laden.
Wir bauten ihn in rund sechs Wochen. Er hatte nicht alle Features. Die Navigation war vereinfacht, die Manipulation halbautomatisiert, und das Finish war purer Engineering-Prototyp. Aber er schloss sich an echte Fahrzeuge an und lud sie. Diese Unterscheidung, zwischen etwas, das beeindruckend aussieht, und etwas, das tatsaechlich funktioniert, stellte sich als die wichtigste Scoping-Entscheidung des Projekts heraus.
Die Computer-Vision-Pipeline
Ein Stueck echter, eingesetzter Software war die CV-Pipeline zur Pruefung des Ladestatus und Extraktion von Ladedaten. Das war pragmatisches Engineering fuer die Prototyp-Phase: Da wir die volle Ladesequenz noch nicht zuverlaessig automatisieren konnten, brauchten wir eine Moeglichkeit, zu ueberwachen und zu verifizieren, was passiert. Die Pipeline nutzte Kamerafeeds, um festzustellen, ob ein Fahrzeug angeschlossen, im Ladevorgang oder fertig war, und extrahierte die relevanten Daten fuer die Berichterstattung.
Simulation-First-Entwicklung
Da Hardware verspaetet war, setzte ich stark auf Simulation. Der Ansatz war zweistufig:
MuJoCo fuer schnelle Iteration und Demos. MuJocos schnelle Physik und sauberes Rendering machten es ideal fuer rasche Konzeptvalidierung und Investoren-Demonstrationen. Wenn ein Investor den Roboter in Aktion sehen wollte, konnten wir innerhalb von Tagen nach einer Designaenderung eine realistische Simulation zeigen, statt Wochen auf Hardware-Iterationen zu warten.
Gazebo fuer Engineering-Validierung. Fuer die eigentliche Robotik-Entwicklung lieferten ROS2-integrierte Gazebo-Simulationen die ingenieurmaessige Genauigkeit, die wir brauchten. Sensormodelle, Physik-Interaktionen und ROS2-Message-Flows entsprachen dem, was das reale System produzieren wuerde, sodass in Gazebo entwickelte Algorithmen mit minimaler Anpassung auf Hardware uebertragen werden konnten.
Dieser zweigleisige Ansatz liess uns den vollen Autonomie-Stack entwickeln und validieren, ohne auf Hardware zu warten, die nicht kam. Es ist nicht dasselbe wie reale Validierung, und ich werde nicht so tun als ob. Aber es bedeutete, dass wir bei Verfuegbarkeit von Hardware softwareseitig nicht bei null anfangen wuerden.
Finanzierung durch technische Meilensteine
Trotz fehlendem vollstaendigen Roboter sicherten wir ueber 250.000 Euro Foerderung. Das gelang, weil wir echten technischen Fortschritt demonstrieren konnten: den funktionierenden Prototyp, der tatsaechlich Autos lud, die Simulationspipeline, die das volle Autonomiekonzept zeigte, und das CV-System, das bewies, dass wir echte Daten von echten Fahrzeugen extrahieren konnten. Technische Meilensteine, wenn sie ehrlich und gut praesentiert sind, koennen in fruehen Phasen ein poliertes Produkt ersetzen.
Lektionen fuer Hardware-Gruender
Simulation-First ist kein Kompromiss
Als ich anfing, auf Simulation zu setzen, fuehlte es sich wie ein Ausweichmanoever an. "Wir koennen das Echte nicht bauen, also simulieren wir es." Aber ich bin mittlerweile ueberzeugt, dass Simulation-First tatsaechlich der richtige Standard-Ansatz fuer jedes Robotik-Startup ist, auch wenn Hardware verfuegbar ist.
Der Unterschied in der Iterationsgeschwindigkeit ist enorm. Eine Designaenderung in der Simulation braucht Stunden. Dieselbe Aenderung in Hardware dauert Wochen, wenn du Glueck hast. Die Moeglichkeit, Hunderte von Szenarien, Fehlermodi und Grenzfaellen in der Simulation zu testen, bevor du dich auf Hardware festlegst, spart echtes Geld und echte Zeit.
Der Schluessel ist, ehrlich mit dir selbst zu sein, was Simulation beweist und was nicht. Sie beweist, dass deine Algorithmen funktionieren. Sie beweist, dass deine Architektur die Zustandsuebergaenge korrekt behandelt. Sie beweist nicht, dass dein Roboter nicht auf nassem Asphalt rutscht oder dass dein Stecker die Kraft aushaelt, die zum Einstecken in einen echten Ladeanschluss noetig ist. Diese Luecke ist real, und sie zu ignorieren raecht sich frueher oder spaeter.
Scope den Prototyp, nicht die Vision
Die wichtigste Entscheidung bei VoltVogel war, einen Works-Like-Prototyp zu bauen, anstatt eine abgespeckte Version des vollen Produkts. Das sind verschiedene Dinge.
Ein abgespecktes Produkt versucht alles zu tun, nur schlechter. Ein Works-Like-Prototyp tut eine Sache, das zentrale Wertversprechen, und tut sie echt. Unser Prototyp lud echte Autos. Er navigierte nicht autonom, sah nicht huebsch aus und haette keine Messe ueberlebt. Aber er bewies das, was zaehlte: Das grundlegende Wertversprechen funktioniert.
Wenn du mit Investoren und Kunden sprichst, gibt es eine Beweishierarchie. "Es funktioniert in der Simulation" ist gut. "Es funktioniert an einem echten Auto" ist viel besser. Selbst wenn der Rest des Systems noch nicht da ist, verankert dieser eine reale Beweispunkt alles andere.
Wisse, was du gebaut hast
Das ist die haerteste Lektion. Nach Monaten intensiver Arbeit ist die Versuchung gross, alles als Erfolg zu framen. Wir haben den Prototyp gebaut. Wir haben Foerderung gesichert. Wir hatten Kunden.
Das stimmt alles. Und es stimmt ebenso, dass wir den vollen Roboter nie gebaut haben. Der Autonomie-Stack war nur in der Simulation. Die Trajektorie des Unternehmens folgte nicht dem Plan. Ehrlich darueber zu sein, was du gebaut hast und was nicht, ist wichtig. Nicht nur ethisch, sondern auch praktisch: Wenn du aufblaeht, was du erreicht hast, triffst du Entscheidungen auf Basis falschen Vertrauens, und diese Entscheidungen holen dich irgendwann ein.
Was ich anders machen wuerde
Wenn ich VoltVogel heute noch einmal starten wuerde, wuerden sich drei Dinge aendern.
Erstens wuerde ich mit einer strukturierten Robotik-Machbarkeitsstudie beginnen, bevor ich mich auf das volle Systemdesign festlege. Nicht eine schnelle Skizze auf dem Whiteboard, sondern eine saubere technische Bewertung dessen, was mit verfuegbaren Komponenten machbar ist, realistische Zeitplaene und eine ehrliche Risikoidentifikation. Wir haben das Lieferkettenrisiko unterschaetzt, weil wir es nicht systematisch evaluiert haben.
Zweitens wuerde ich das technische MVP von Tag eins rigoroser definieren. Die Unterscheidung zwischen "Works-Like-Prototyp" und "vollem Produkt" sollte explizit am Anfang getroffen werden, nicht unter Druck entdeckt werden, wenn Teile nicht ankommen. Zu wissen, was dein MVP wirklich beweisen muss und was nicht, spart Monate fehlgeleiteter Arbeit.
Drittens wuerde ich die Fundraising-Erzaehlung sorgfaeltiger von der Engineering-Realitaet trennen. Wir haben gleichzeitig fuer Investoren und fuer Engineering-Validierung gebaut, und das sind verschiedene Aktivitaeten mit verschiedenen Anforderungen. Ein Fractional CTO, der Hardware-Fundraising schon durchgemacht hat, kann Gruendern helfen, diese Spannung zu navigieren, ohne die technische Integritaet zu verlieren.
VoltVogel hat mich mehr ueber den Bau von Hardware-Produkten gelehrt als jede Erfolgsgeschichte es koennte. Die Simulations-Workflows, das Prototyp-Scoping, die ehrliche Bewertung dessen, was funktioniert und was nicht, das sind Faehigkeiten, die ich jeden Tag in meiner Beratungsarbeit einsetze. Manchmal ist die wertvollste Fallstudie die, in der du ehrlich ueber die Luecke zwischen Vision und Realitaet bist.
