Terug naar projecten

Smart Bin Kiosk

AI-kiosk die laat zien in welke afvalbak je voorwerp hoort, en hoe zeker hij dat weet.

OpleidingJuli 2026
JavaScriptHTMLCSSPythonFastAPIOllamaGemmaRF-DETR

Over het project

Bijna iedereen scheidt afval, en toch gaat het bij de bak alsnog mis. Uit onze enquête (N = 47) bleek dat 81% vaak of altijd scheidt, maar dat 30% twijfelt over de juiste bak. Het knelpunt is dus niet motivatie maar onzekerheid. Daar kwam bij dat datzelfde publiek AI nauwelijks herkent in het dagelijks leven, en dat geen enkele respondent een AI-advies volledig zei te vertrouwen.

De opdracht kwam van het Lectoraat Data Intelligence van Zuyd Hogeschool, dat duurzame technologie zichtbaar wil maken voor een breed publiek. Met onze casusgroep kwamen we op het idee om dat te doen met een smart-bin-kiosk: je houdt een voorwerp voor de camera en het scherm laat zien in welke van de zeven Nederlandse afvalstromen het hoort, waarom, en hoe zeker het systeem daarvan is.

De kiosk werkt in drie fasen. In de live-fase zoekt een objectdetector een paar keer per seconde waar het voorwerp in beeld zit en speurt de backend naar een streepjescode. Die positie staat niet op het scherm, want het startscherm moest rustig blijven, maar hij wordt wel gebruikt: de streepjescodelezer krijgt precies dat stukje beeld, en verdwijnt het voorwerp, dan springt de kiosk terug naar de startstand.

Bij een druk op de knop of een gevonden streepjescode bevriest het beeld en splitst de route zich. Een streepjescode gaat naar de productdatabank Open Food Facts, die de verpakkingsmaterialen van dat exacte product teruggeeft. Is er geen code, dan gaat het hele frame naar Gemma, een vision-taalmodel dat lokaal via Ollama draait. Welk antwoord wint, ligt vast in een vaste volgorde: eerst de productdatabank, dan het taalmodel, dan de detector, en anders restafval.

Het advies is niet altijd één bak. Een koffiebeker valt uiteen in een kartonnen beker (restafval) en een plastic deksel (PMD); die onderdelen staan apart op het resultaatscherm met de bak die erbij hoort. Alles draait lokaal op één laptop, want privacy kwam als harde eis uit de enquête: beelden verlaten de machine niet en worden niet opgeslagen. Daarom is er ook geen online demo: je hebt er een camera en een lokaal draaiend AI-model bij nodig. De code staat wel op GitHub.

Voor de zekerheid gebruikten we een stoplicht in plaats van een percentage. Een streepjescode-opzoeking is gezaghebbend en krijgt groen. Een inschatting van de AI komt nooit verder dan oranje, met het label "uitleg door AI" ernaast. Zakt de zekerheid onder de drempel, dan geeft de kiosk geen advies maar zegt hij dat hij het niet weet en kiest de bezoeker zelf. Percentages staan er nergens, omdat uit de literatuur bleek dat leken die overschatten. Alle teksten staan op B1-niveau, in het Nederlands en het Engels.

Ik heb de kiosk-interface gebouwd, dus alles wat de bezoeker ziet: een state machine over de fasen aantrekken, scannen en resultaat, plus een "hoe werkt dit?"-scherm dat in vijf regels uitlegt dat er AI meekijkt en dat die kan twijfelen. Daarnaast een verborgen beheerscherm voor de standbeheerder. Daarin zet hij aan welke bakken er die dag staan en sleept hij ze naar hun plek in de zaal, zodat de pijl op het scherm naar de echte bak wijst. Ontbreekt een bak, dan valt het advies terug op restafval met uitleg waarom.

Naast de bouw werkte ik mee aan het onderzoek en de rapportage. Het project liep volgens Design Science Research, met drie cycli: interviews en de enquête voor de eisen, literatuuronderzoek als fundament, en bouwen en meten als derde. In die derde cyclus testten we één ontwerpkeuze A/B: de richtingspijl. Variant A toonde een neutrale strook met alle bakken, variant B liet de doelbak oplichten met een pijl. Tien deelnemers deden beide varianten met zes voorwerpen per variant. Met de pijl kozen ze gemiddeld in 4,60 seconden tegenover 7,50 seconden zonder (t(9) = 3,80, p = 0,004), en negen van de tien vonden hem prettiger.

De grootste wending zat in de techniek. De eerste werkende versie gebruikte een objectdetector die tegelijk lokaliseerde en classificeerde. Op papier deed die het goed: op ruim duizend testbeelden won RF-DETR van YOLO11 (macro-F1 0,705 tegenover 0,455) en na kalibratie zakte de verwachte kalibratiefout van 0,228 naar 0,023. Met een webcam erbij viel het uit elkaar door een gezicht in beeld, een rommelige achtergrond en voorwerpen die op niets uit de trainingsdata leken. Textiel en elektro kon het model sowieso niet herkennen, want daar zaten nul voorbeelden van in de data. Halverwege stapten we daarom over op de opzet met Gemma.

Precies daarvoor is de design-cyclus van DSR bedoeld: bouwen, evalueren in de echte context, en bijsturen op wat je meet. We hebben de omslag daarom vastgelegd in een apart beslisdocument, met de afweging en de gevolgen voor de deelvragen, in plaats van hem weg te poetsen.

Het volledige eindrapport van dit onderzoek staat bovenaan deze pagina als pdf. Daarin staan de methode, de enquête- en A/B-analyse en de literatuur volledig uitgewerkt.

Wat ik heb geleerd

Het lastigste aan deze interface was niet de indeling maar de eerlijkheid. Een percentage op het scherm voelt exact, maar uit het onderzoek bleek dat een leek er te veel waarde aan hecht. Ik heb daarom alle percentages eruit gehaald en vervangen door een stoplicht met één woord, en er een toestand bij gebouwd waarin de kiosk toegeeft dat hij het niet weet. Dat voelde eerst als een zwaktebod, tot bleek dat geen enkele respondent een AI-advies volledig vertrouwt. Juist die twijfel-toestand maakte het geheel geloofwaardiger. Ik ontwerp sindsdien liever een scherm dat zijn grenzen laat zien dan een scherm dat zekerheid nabootst.

Wat het samenwerken makkelijk maakte, was dat we vooraf één antwoordvorm hebben vastgelegd waar beide routes in passen: welke bak, welke onderdelen, welke zekerheid en waar het antwoord vandaan komt. Mijn front-end hoefde daardoor nooit te weten of het antwoord uit de productdatabank of uit het taalmodel kwam. Toen de hele classificatie halverwege omging naar Gemma, veranderde er aan de schermen bijna niets. Die afspraak kostte aan het begin een uur discussie en scheelde daarna weken.

De A/B-test liet me zien hoe je een ontwerpdiscussie beëindigt. Of die richtingspijl echt hielp of alleen mooi stond, was in het team een kwestie van meningen. We hebben het gemeten, en 2,9 seconden verschil maakte het gesprek in één keer klaar. Minstens zo nuttig was wat de test blootlegde over onze eigen oplossing: bij een voorwerp dat in twee bakken uiteenvalt kan één pijl niet naar twee kanten wijzen, dus daar bleef de twijfel staan. Een test die alleen bevestigt wat je hoopte, heb je niet goed opgezet.

Verder heb ik gezien hoe ver een benchmark naast de werkelijkheid kan liggen. Zodra onze detector een voorwerp gevonden had, koos hij in 96% van de gevallen de juiste bak. Op papier een gelopen race, tot we er een webcam aan hingen en het model op een gezicht en een rommelig bureau de weg kwijt was. De testset bestond uit nette, uitgelichte foto's, dus we hadden vooral gemeten hoe goed het model op nette, uitgelichte foto's was. Test zo vroeg mogelijk in de echte opstelling, en weet bij een cijfer altijd waarop het gemeten is.

Tot slot was dit mijn eerste project met AI en machine learning erin, en dat bouwt anders. Gewone code doet bij dezelfde invoer altijd hetzelfde; een model geeft een inschatting die de volgende keer anders kan uitvallen. Je kunt dus geen test schrijven die eist dat er "plastic" uit komt, en daarom draait onze testsuite op nepversies van de detector, het taalmodel en de productdatabank: we toetsen wat wij eromheen gebouwd hebben, niet het model zelf. Net zo goed moet je ontwerpen voor een fout antwoord, vandaar de vaste volgorde waarin de routes elkaar opvangen, de twijfel-toestand en een aparte kaart voor als het model niet reageert. En waar gewone code milliseconden kost, doet zo'n model er seconden over. Dat bevroren beeld met "even geduld" is dus geen versiering maar de plek waar die wachttijd landt.

Beelden