Prosjekt JavaZone stand 2023

Konseptet for standen vår på årets JavaZone var en robotbane, hvor besøkende skulle kunne programmere et lite robotkjøretøy til å navigere en bane og score mest mulig poeng.

Vi landet på BitBot XL som robot, av følgende grunner:

• Passe størrelse
• Innebygget linjesensor, så den kan holde seg på banen
• Styres av BBC micro:bit, som det allerede finnes en mengde programmeringsressurser til.

Til programmering av BitBot’en valgte vi MicroPython, et Python bibliotek laget for micro:bit. Det finnes mye gode eksempler på MicroPython, inkludert kode for å kontrollere motor og linjesensorer på BitBot XL. MicroPython har også ganske god IDE støtte.

MicroPython fungerer ved at man først laster inn et Python runtime miljø på en micro:bit, og deretter kan man laste opp sine egne Python skript. Dette viste seg etterhvert å innebære noen utfordringer, ettersom Python runtime tok såpass stor plass i micro:bit’en at det var lite plass igjen til våre egne skript. Dette oppdaget vi først et stykke inn i prosjektet etterhvert som vi la til mer og mer funksjonalitet i koden. Vi brukte to micro:bits av gangen i dette prosjektet; en var koblet til BitBot’en og en annen var koblet til en PC med USB kabel. Denne fungerte som en kommunikasjons bro mellom PC og BitBot, den kommuniserte med micro:bit’en på BitBot via radio (innebygget i micro:bit).

BitBot XL har som nevnt en linjesensor, eller spesifikt to sensorer som skiller mellom svart/ikke svart farge, plassert på høyre og venstre side. Hvis BitBoten kjører på en linje vil sensoren slå ut på en side hvis BitBoten er i ferd med å krysse linjen, så ved å korrigere med små svinger til høyre eller venstre kan den plassere seg så linjen passerer rett under kjøretøyet.
I hvert fall i teorien. Vi oppdaget raskt at linjesensorene kunne være litt uforutsigbare. Det grå gulvet på kontoret ble ofte vurdert som svart, mens en svart linje trykket på et hvitt ark ikke ble detektert. Linjer med svart elektroteip på en lys voksduk ga derimot et pålitelig kjøreunderlag.

Planen vår ble å lage en bane med et rutenett av svarte linjer, og at BitBot’en skulle kunne følge linjene og svinge 90 grader høyre eller venstre der linjene krysset. Vi forsøkte å detektere kryssene ved å teste om begge sensorene slo ut samtidig, men dette viste seg å være upålitelig, så vi gikk for å integrere en RFID sensor i BitBot’en, og legge RFID-brikker under banen ved hvert kryss. Ved å lage et kart over ID-koden til hver RFID-brikke kunne vi vite nøyaktig hvor BitBoten var på banen.

Når vi hadde dette kartet kunne vi også tilegne passende antall poeng til hvert punkt på rutenettet, fra -2 til 6. Tanken var at spilleren skulle programmere en rute på forhånd, i et lite skript-språk vi laget for anledningen. Kjøreruten ville så lastes opp til BitBot’en, som ville kjøre den i maks 20 sekunder. For å score mest poeng ville det gjelde å planlegge den mest effektive ruten gjennom banen.
Det store spørsmålet som vi ikke kunne svare på før det hele nærmest var ferdig var om det egentlig ville bli noe morsomt. Ville det være passe utfordrende å finne en god rute over brettet, eller ville det være åpenbart for de fleste hvordan man burde kjøre? Før vi kom så langt som å teste dette kom en av oss på at dette konseptet med roboter som kunne programmeres til å svinge i 90 grader og kjøre i forskjellige retninger lignet på det klassiske brettspillet Roborally!

Å styre BitBot’en med spillkort virket som en morsom ide. Siden vi var godt i gang med Python allerede, fikk vi raskt satt sammen en prototype på en app som lot brukeren trekke en hånd på 5 kort som var et tilfeldig utvalg av kjøring i forskjellige retninger, brukeren fikk så 30 sekunder på å arrangere kortene i en rekkefølge for å kjøre innom best mulig poengpunkter. Allerede i de første testene var dette ordentlig morsomt. Vi endte etterhvert opp med at spilleren fikk 6 kort og kunne spille 4 av dem, og spilte 3 runder av gangen. Noe av utfordringen for spillerne var at siden man ikke kunne vite hvilke kort man fikk neste rute, måtte man planlegge for forskjellige muligheter med hvor man kjørte BitBoten sist i hver runde. Var man uheldig og stoppet i et hjørne, var det ikke sikkert man fikk riktige kort for å komme seg ut neste runde!
Nå hadde vi et solid konsept på plass. Med hjelp av AI-bildegenerering fikk vi pyntet på prototypen til noe som så ut ganske bra ut.

Årets JavaZone tema var Sirkus, og når vi kombinerte det med vårt robotkonsept og litt håndlaget design så fikk vi laget et lite robo-sirkus-rally.

Det var knapt med tid før JavaZone, så vi rakk ikke teste så mye som vi skulle ønsket før konferansen begynte. De første timene på JavaZone ble ganske stressende da vi måtte tilpasse spillet for å fikse en rekke feil vi ikke hadde oppdaget før. Det største problemet var noe helt nytt; radiokommunikasjonen mellom micro:bit’ene koblet til PC og BitBot XL viste seg å være upålitelig. Dette hadde fungert uten problemer når vi testet på kontoret i ukene før, men inne på Oslo Spektrum var det nok endel mer radiostøy i luften, og mange radiomeldinger som ble sendt mellom micro:bit’ene kom aldri frem, noe som skapte store problemer da vi enten ikke fikk lastet opp kjøreinstrukser til BitBot, eller rapportert tilbake hvor på banen BitBot’en var, og dermed hvor mange poeng spilleren hadde fått.
En optimal løsning på dette kunne vært å lage en robust kommunikasjonsprotokoll med Ack meldinger og re-sending av feilede meldinger, men siden vi hadde knapt med tid og det stod folk ved standen og ventet på å spille, la vi heller til en kjapp fiks hvor micro:bit sendte alle meldinger fem ganger med noen millisekunders mellomrom. Dette fungerte bra i praksis, det var alltid minst en melding som kom gjennom.
Til tross for en hakkete start, etter noen timer var spillet oppe og kjørte i full gang. Det var en umiddelbar suksess, det var nærmest konstant folk på standen for å spille, og flere kom tilbake senere i JavaZone for å spille på nytt. Det dukket opp noen tekniske småfeil til i løpet av konferansen, men de lot seg kjapt fikse, og vi gjorde også noen små justeringer på brukergrensesnittet etterhvert som vi så at noen elementer kunne misforstås. Alt i alt viser dette viktigheten av å ha teknologi som gjør det mulig å gjøre raske endringer når koden møter virkeligheten.

Les mer her: https://github.com/jprofessionals/pn532

WebApp.

For å holde oversikt over deltakernes poengsummer, utviklet vi en web-applikasjon. Teknologiene som ble valgt for dette inkluderte Svelte for Frontend og SvelteKit for enkel ruting og api-endepunkter, TypeScript for å sikre type-sikkerhet i koden, Supabase for databaselagring, og Vercel for enkel hosting. Disse teknologiene muliggjør rask og effektiv utvikling og deployering av en funksjonell applikasjon.

Applikasjonen var designet for å være intuitiv og brukervennlig. Via et POST-endepunkt kunne spillet på datamaskinen sende inn deltakerens poengsum etter hver runde, med e-post om de ville være med i trekningen. Et enkelt GET-endepunkt på SvelteKit applikasjonen gjorde det enkelt å hente top 20 poengsummer og liste ut i en artig Svelte-komponent designet og utviklet for anledningen. Gitt tidspresset før JavaZone, var en av de største fordelene med denne teknologi-stacken hastigheten fra utvikling til produksjonsklar applikasjon.

Frontenden ble bygd med Svelte, noe som muliggjorde en reaktiv og moderne brukeropplevelse. SvelteKit hjalp med å organisere koden og forenkle ruting mellom de forskjellige sidene i applikasjonen og lot oss utvikle egne api-endepunkter som kjørte som server-løse funksjoner på Vercel sin plattform. TypeScript og Zod ble brukt for å sikre korrekt håndtering og validering av data gjennom applikasjonen.

På baksiden brukte vi Supabase for databaselagring, som gjorde det enkelt å sette opp og administrere en database. Supabase vedlikeholder en JavaScript klient som kan installeres som en egen pakke, for å enkelt kunne hente ut data fra databasen. Dette gjorde det lekende lett å utvikle raskt og sette på plass funksjonalitet for å hente og sende data om deltakernes resultater.

Hosting på Vercel var problemfritt, og gjorde det mulig å distribuere applikasjonen til en live URL med bare noen få klikk. Som nevnt tidligere, kan man også eksponere egne endepunkter som kjører Serverless på deres plattform, som frigjør oss fra arbeidet med å sette opp en egen server for å utvikle en fullstack-applikasjon.

Samlet sett gjorde disse teknologiene det mulig å raskt utvikle en robust og brukervennlig applikasjon som fungerte som et tilskudd til standen vår. Deltakerne som var blant top 20 kunne enkelt se deres poengsum og sammenligne seg med andre, noe som skapte en morsom og konkurransepreget atmosfære. Applikasjonens suksess, sammen med den positive responsen på robotbanen, gjorde vår deltakelse i JavaZone 2023 til en stor suksess!

Vi er også heldige nok til å ha en grafisk designer på laget som kunne designe baner til prosjektet:

Bane 1	Bane 2