BrickBack — wie es entstanden ist

Warum überhaupt

Mein Sohn und ich hatten den UCS Millennium Falcon (75192) gebaut — über 7.500 Teile, 17 nummerierte Tütengruppen. Irgendwann lag das Set zerlegt in einem großen Sack, und der Wiederaufbau scheiterte an einer einzigen Sache: ein bestimmtes Teil im Haufen wiederzufinden. Es gibt Apps, die Haufen erkennen (Brickit) oder Einzelteile (Brickognize), aber keine, die einen zerlegten Berg wieder den originalen Bauabschnitts-Tüten zuordnet. Genau das wollte ich haben.

Wie es funktioniert

Der Ablauf ist bewusst simpel: Set auswählen, ein Foto vom flach ausgebreiteten Teilehaufen machen, die App erkennt jedes Teil und zeigt per farbigem Overlay, in welche Tüte es gehört. Weggsortiert, nächstes Foto vom Resthaufen — bis der Berg leer ist. Am Ende steht eine Fehlteilliste mit Tütenzuordnung, die sich direkt als Einkaufsliste nutzen lässt.

Was drinsteckt

Die App ist in Flutter geschrieben (Android zuerst, iOS folgt), der Zustand läuft über Riverpod, die lokale Datenbank über drift auf SQLite — der Sortierfortschritt übersteht App-Neustarts. Technisch besteht das Projekt aus vier Bausteinen:

• Inventar & Tüten-Mapping — der eigentliche Kern. Welches Teil in welche Tüte gehört, steht in keiner Datenbank. Ich berechne es einmal pro Set offline aus der Textebene der Anleitungs-PDF (Inventar, Mengen, Tüten-Badges); OpenCV findet die Teile-Callouts, Brickognize liefert die Teile-Identität — mit eingebauter Validierung, dass die Summe der Tüten plus Ersatzteile dem Gesamtinventar entspricht.
• Objekt-Erkennung — ein YOLOv8n-Detektor schneidet jedes Teil aus dem Foto. Die Trainingsdaten rendere ich synthetisch aus LDraw-3D-Modellen; das Modell läuft on-device als TFLite.
• Klassifikation — jeder ausgeschnittene Crop wird zur Teilenummer. Im MVP über die Brickognize-API, später ein eigenes On-Device-Modell, das nur die rund 700 Teiletypen des jeweiligen Sets kennt.
• Matching — erkanntes Teil vom Restbedarf abbuchen, bei Mehrdeutigkeit die Tüte mit dem größten Restbedarf vorschlagen.

Das Backend

Damit die App nicht jedes Set selbst vorberechnen muss, gibt es einen kleinen Content-Service: ein FastAPI-Dienst, der versionierte Set-Bundles (Inventar + Tüten-Mapping + optionale Erkennungsdaten) in PostgreSQL hält und read-only an die App ausliefert. Die Offline-Pipeline, die die Mappings erzeugt, teilt sich das Daten-Schema mit dem Service, sodass beide Seiten denselben Vertrag sprechen. Die App selbst kommt im MVP ohne Server aus — das Backend ist die Infrastruktur dahinter, die neue Sets nachliefert.

Was kniffeliger war

• Grau auf Grau: Der Falcon ist fast monochrom. Die App empfiehlt einen dunklen, kontrastreichen Untergrund, sonst verschwimmen die Teile.
• Verwechslergruppen: 1×2-Plate vs. Tile, flache Slopes von oben — kaum zu unterscheiden. Unter einer Confidence-Schwelle fragt die App lieber nach, statt zu raten.
• Markenrecht: „LEGO" darf nicht im App-Namen stehen. Daher BrickBack und die Formulierung „für Klemmbausteine geeignet".

Stand heute

Der Sortier-Workflow steht für das erste Set (75192) mit Brickognize als Erkennung. Als Nächstes: die Mapping-Pipeline für weitere Sets, eigene On-Device-Modelle und der Weg in die App-Stores. Die Store-Links kommen hierher, sobald die App veröffentlicht ist.