Erster Platz beim KOSTAL Hackathon 2025
Die halbe Bauzeit ging für Batterieprobleme drauf. Den Rest haben wir bewusst in das langsamere Auto gesteckt, und genau deshalb gewonnen.
Den Lauf ansehen: KOSTAL Hackathon 2025 ↗
Die Aufgabe beim KOSTAL Hackathon 2025 war konkret: Ein Raspberry-Pi-Auto
musste einem markierten Pfad folgen, unterwegs QR-Codes lesen und den
Parcours abschließen. Acht Stunden standen im Zeitplan. Gewonnen haben wir
mit etwa vier.
Die vier Stunden, die wir nicht eingeplant hatten
Akkuprobleme haben die erste Tageshälfte gefressen. Nicht dramatisch – kein
Rauch, keine tote Hardware –, sondern die schleichende Art von Fehler, bei
der sich das Auto im dritten Durchlauf anders verhält als im ersten und man
eine Stunde damit verbringt festzustellen, dass der Code in Ordnung ist und
der Strom nicht.
Genau diese Stunde entscheidet Hackathons, und sie steht in keinem Plan.
Übrig blieben uns damit etwa vier Stunden für alles: die Steuerlogik
schreiben, den Lauf planen und gerade so viel testen, dass wir ihr
vertrauen konnten.
Warum wir bewusst das langsamere Auto gebaut haben
Wenn die Hälfte der Zeit weg ist, liegt es nahe, schneller zu werden. Wir
haben das Gegenteil gemacht, und diese Entscheidung ist der Grund für
diesen Beitrag.
Die schnellen Ansätze hatten alle dieselbe Form: Im Normalfall liefen sie
hervorragend, und dazu gab es eine Reihe von Situationen, in denen sie es
nicht taten. Eine engere Linie durch die Kurve ist schneller, bis die
Markierung aus dem Blickfeld verschwindet. Eine höhere Geschwindigkeit
zwischen den Checkpoints bringt Sekunden, bis eine Fehllesung das Auto vom
Pfad abbringt und jemand es von Hand zurücksetzen muss.
Jeder dieser Randfälle ist eine Debugging-Session, und die hatten wir nicht
mehr übrig. Die Regel für den Rest des Tages lautete deshalb: die Option
mit weniger Möglichkeiten zu scheitern bevorzugen, auch wenn sie sichtbar
langsamer ist.
In der Praxis hieß das: vorsichtige Geschwindigkeiten, großzügige Spielräume
dort, wo das Auto etwas erkennen musste, und eine Steuerlogik, die so
einfach war, dass man sie durchdenken konnte, ohne sie auszuführen. Nichts
am Aufbau war clever. Das war der Punkt.
Bewertet wird die Zuverlässigkeit
Es fühlte sich dabei zu vorsichtig an. Andere Teams waren sichtbar
schneller, und ein langsames Auto sieht aus wie ein Auto, das nicht fertig
ist.
Aber ein Hackathon wird nicht nach dem besten Lauf bewertet, sondern nach
dem Lauf, der einmal vor den Juroren stattfindet. Ein Auto, das den
Parcours mit achtzig Prozent der Geschwindigkeit schafft, schlägt eins, das
doppelt so schnell ist und bei jedem dritten Versuch scheitert. Bei dieser
Bewertung ist „langsam und sicher“ keine ängstliche Wahl, sondern die
richtige, und in der Lücke zwischen diesen beiden Lesarten verliert der
Großteil des Feldes.
Unser Stack blieb bewusst klein: das Raspberry-Pi-Auto, Python für die
Steuerung und einfache Prüfungen, die es auf dem Pfad halten. Mit vier
Stunden ist nicht die Frage, was man bauen kann, sondern was man noch
überprüfen kann.
Was ich daraus mitgenommen habe
Der technische Teil dieses Tages war unspektakulär, und genau das finde ich
das Interessante. Wir haben nicht gewonnen, weil wir besseren Code
geschrieben haben als alle anderen. Wir haben gewonnen, weil wir unsere
restliche Zeit auf das verwendet haben, was das Ergebnis am ehesten
entscheidet, und uns dann geweigert haben, das gegen Geschwindigkeit
einzutauschen, die wir nicht brauchten.
Unter Zeitdruck ist der Instinkt, die Arbeit zusammenzustauchen. Besser ist
es, das Risiko zusammenzustauchen: festlegen, was nicht scheitern darf,
und alles andere langsamer sein lassen, als es sein könnte.