Dit zijn de broers Jeffrey en Marc. Hun project? Een QR code van lego maken. Best een QRankzinnig idee!
Het idee
Maak een QR code van lego die uit 9 blokjes en 4 verschillende kleuren bestaat. Gebruik vervolgens de webcam en de API in Chrome om deze QR code te lezen. En bedenk een manier waarop je, ondanks de beperkte hoeveelheid data in de QR code, toch iets kunt bereiken. Een 'normale' QR code kan namelijk veel meer data bevatten. De meest gangbare QR-code versies, versie 1 en versie 3 hebben respectievelijk 21x21 en 29x29 modules.
Een module in een QR code is een zwart of wit blokje, en de aanwezigheid van zo'n blokje bepaalt de waarde van die specifieke module (in computer-termen is dat bijv 1 of 0). Versimpeld uitgelegd kan je bijvoorbeeld met 21x21 modules een woord (of zin) van 25 karakters vastleggen. Met de 29x29 variant zijn dat al 77 karakters. Het achterhalen van de data-capaciteit heeft een aantal stappen - de 3 hoeken van een een QR code worden gevonden om de scanner te 'oriënteren', en alleen de overgebleven modules bevatten de daadwerkelijke data. Maar een deel daarvan wordt gebruikt voor foutcorrectie.
Uiteindelijk blijft er bij versie 1 van de bestaande QR codes ongeveer 152 modules over voor de daadwerkelijke informatie (dit noemen we ook wel de 'payload'). Marc en Jeffrey hadden een QR code die slechts 13 modules had. Slechts 13 modules? Dus eigenlijk 13 bits? Als je uitgaat van een 8-bit encoding, is dat niet eens genoeg voor 2 karakters! Je kunt dus niet eens het woord 'Hi' coderen in de QR code.
De uitdaging
De uitdaging is dus om met zo weinig modules toch een manier te vinden om meer data vast te kunnen leggen. Het was dus tijd voor Jeffrey en Marc om wat creatiever te worden.
Encoding Zoals hierboven uitgelegd: er zijn 8 modules nodig om 1 letter te tonen. Hoe werkt dat? Iedere module in een QR-code heeft twee mogelijkheden: Hij is er WEL of hij is er NIET. Als je 2 modules combineert, heb je twee keer twee mogelijkheden (dus 4). Voor iedere module die je toevoegt aan deze reeks vermenigvuldig je het aantal mogelijkheden met 2. Bij 8 modules heb je dus 2x2x2x2x2x2x2x2=256 verschillende combinaties. Iedere combinatie representeert een karakter, zoals een 'a', 'b', 'B', '4', of '.'. Dus bijvoorbeeld letters, hoofdletters, cijfers, leestekens en spaties.
Dit concept noemen we een 'encoding formaat'. Maar dit formaat is slechts een afspraak. We kunnen ook afspreken dat slechts 5 (dus 2x2x2x2x2) combinaties van modules gebruiken, en dan alleen kleine letters kunnen representeren. Dan wordt het opeens mogelijk om meer informatie kwijt te kunnen in dezelfde oppervlakte.
Verhoging van data dichtheid door positie mee te nemen Marc en Jeffrey gingen nog een stapje verder: het encoding formaat is afhankelijk van de positie van de module. De eerste module representeerde niet meer een deel van een karakter, maar zelfs een gehele website. Bijvoorbeeld: is module 1 aanwezig? Dan is de website instagram. Is module 1 niet aanwezig? Dan gaan we naar youtube.
Je verhoogt dus de dichtheid van je data door je encoding formaat minder flexibel te maken en door extra informatie (de positie van een module) ook een betekenis te geven in je encoding formaat.
Verhoging van data dichtheid door kleur mee te nemen QR codes zijn over het algemeen wit en zwart. Daarom kan een module maar twee waardes hebben. Ook hier zagen de broers een kans: wat als we nou eens 6 kleuren gebruiken? Namelijk zwart, wit, rood, geel, blauw en groen? Iedere module heeft dan 6 mogelijke waardes, en combinaties van waardes groeien dan ook snel. Twee modules hebben dan al 6x6=36 combinaties!
Dit werkt ook gewoon samen met hun vorige stap, waarbij de positie ook van invloed was: De eerste module kan nog steeds een website representeren, maar nu is er opeens de keuze uit 6 verschillende websites.
Concreet Het uiteindelijke formaat werd een combinatie van manieren om een URL op te bouwen. De eerste module heeft bijvoorbeeld 3 mogelijke waardes: 'https://', 'http://', en 'ftp://'. De tweede module heeft er 4: 'www', 'admin', 'cms', 'mijn'. Misschien zie je inmiddels al waar het naar toe gaat. Module op positie 3 kreeg dan mogelijkheden zoals 'facebook', 'tinyurl', etc. Dit combineren ze vervolgens met een slimme manier om de overige 'vrije' modules om te zetten naar vrije tekst, die er vervolgens bijgeplakt kan worden, afhankelijk van de andere gekozen opties.
Op deze manier weten ze dus hun beperkte hoeveelheid modules erg slim en efficient te gebruiken.
Maar, hoe verliep het in de praktijk?
Knelpunten
Zoals gebruikelijk komen de problemen bij het ontwikkelen van software meestal op de grens waar de software-wereld en de echte wereld met elkaar in aanraking komen. Zo was het interpreteren van kleuren bijvoorbeeld moeilijk, onder invloed van wel of geen daglicht.
Het is natuurlijk niet geheel onverwacht: Dat is natuurlijk ook de reden waarom QR codes zwart-wit zijn. De aanpassing om de data-dichtheid te verhogen brengt altijd weer meer complexiteit met zich mee en meer complexiteit betekent meer plekken waarop het fout kan gaan.
Ze probeerden nog te compenseren door de QR code met matte lak te bespuiten, maar ook dat hielp niet. Gelukkig werkte het tijdens de demo in de avond, met kunstlicht, beter dan overdag met (deels) daglicht.
De werking was dus, afhankelijk van de omstandigheden, niet altijd even betrouwbaar, maar vaak deed hij het wel. Marc en Jeffrey lieten tijdens de demo dus zien hoe ze de lego QR code konden aanpassen en dit resulteerde in andere data. Wat ons betreft was dit dus een leuk en geslaagd hackathon project.
Publicatie en video
Wil je de Lego QR code in actie zien? Neem dan een kijkje naar onze video van de hackathon, waar het bewijs in beeld is gebracht, en waar ook alle andere hackathon-projecten onder de aandacht komen. Je kunt de aftermovie van de hackathon hier bekijken!
Benieuwd naar de andere projecten van de hackathon? Lees dan onze publicatie over deze hackathon, en hou ons techblog de komende weken in de gaten.