Lego Mini Memory Game: 5 trinn (med bilder)

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:23

For et år siden skrev jeg en instruks om installering av en haug med lysdioder i en Lego Mini Cooper. Innovasjonen, slik den var, var at lysdiodene kunne styres med en smarttelefon (eller gjennom hvilken som helst nettleser, for den saks skyld).

Som jeg møysommelig beskrev i den instruksjonsboken, var det meste av innsatsen den gang knyttet til å koble til Mini uten at det hele falt fra hverandre. Litt til min overraskelse overlevde Mini deretter en tur fra Connecticut til Toronto og har jobbet, mer eller mindre, siden.

"Hvis den ikke var ødelagt, fikset han den til den var" blir i beste fall min epitaf, så da Mini kom hjem til jul, var det tid for Lego Mini 2.0. Tross alt, hvis Tesla kan skyve programvareoppdateringer til bilene sine, hvor vanskelig kan det være?

Jeg hadde noen ideer:

• Forbedre det ganske klumpete brukergrensesnittet
• Legg til et horn!
• Forbedre funksjonen "autolys"; og, viktigst
• Legg til en spillfunksjon (selv jeg innså at nyheten med å slå på og av Mini -lampene med telefonen kommer til å falle før eller siden)

Spillfunksjonen var den største oppgaven, ikke minst fordi det ikke umiddelbart var åpenbart for meg hva slags spill det kunne være. Mini er altfor skjør til å opprettholde et spill som involverer at den blir håndtert (unntatt muligens en deprimerende variant av Jenga). En annen hindring var at jeg aldri har programmert et spill i hele mitt liv.

Etter et år med fruktløs grubling, snublet jeg over et prosjekt på Hackster, der en Arduino Uno brukes til å etterligne et minnelek leketøy fra 1970 -tallet kalt Simon. I et nøtteskall spilte Simon -enheten en rekke lys som spilleren deretter måtte huske og spille av ved å trykke på knappene. Etter hver vellykkede runde ble sekvensen økt i lengde.

Til tross for at jeg var av den nødvendige årgangen, hadde jeg faktisk aldri hørt om dette spillet, og jeg må si det er utrolig hva som gikk for moro tilbake på dagen. Enda mer fantastisk er at Simon -spillet fortsatt er på salg, og får strålende anmeldelser på Amazon. Dette måtte tydeligvis være hovedkandidaten for å tilpasse meg mine formål. Tross alt hadde Mini allerede lysene, så alt jeg måtte gjøre var å slippe de fysiske knappene og få brukerinngang levert via en smarttelefon. På programvaresiden så det derfor ut til at dette i stor grad bare ville være en klipp-og-lim-jobb.

Men først måtte jeg gjøre noen mindre endringer i maskinvaren.

Trinn 1: Komponenter, verktøy og ressurser

Hvis du replikerer dette prosjektet med en Lego Mini, trenger du alle tingene som er oppført i min tidligere Instructable. Det eneste ekstra du trenger er en passiv summer, som brukes til hornet og til å lage en haug med irriterende lyder under spillet (som kan deaktiveres).

Som det vil bli klart når vi diskuterer programvaren, er det ikke noe reelt behov for å bruke en Lego Mini til spillet. Du kan bruke et annet Lego -sett, eller en haug med lysdioder på et brødbrett som er koblet til et hvilket som helst ESP8266 -utviklingsbrett. Med noen reléer kan du til og med bruke hjemmets rombelysning. Barn, spør foreldrene dine først om den.

På samme måte er det ikke nødvendig med ytterligere verktøy eller ressurser utover de som er oppført for det opprinnelige prosjektet.

Hvis du er blant en håndfull mennesker som leser den originale prosjektbeskrivelsen, vet du at Lego Mini opprinnelig ble kjøpt som en gave til min voksne datter, som har en nesten identisk "ekte" Mini, eller så godt som identisk med det kan gis at det er en ny mini, ikke en "klassiker". Mangelen på noen meningsfulle tilleggskomponenter gjorde dette nye prosjektet enda mer attraktivt siden det ville gjøre det mulig for meg å re-gave Lego Mini 2.0 på nytt som en ny julegave uten å koste knapt en krone. Geni!

Trinn 2: Maskinvaremodifikasjon

Det opprinnelige prosjektet hadde individuelt kontrollerbare RGB -interiør -lysdioder. Disse brukte tre pinner på NodeMCU, som jeg brukte som utviklingstavle. Etter diskret samråd med Lego Mini -eieren ble det bestemt at RGB -lysdiodene var en underbrukt funksjon. Dette var viktig intelligens fordi jeg trengte å frigjøre en pin for summeren/hornet.

Kretsdiagrammet ovenfor er fra det opprinnelige prosjektet. Den eneste endringen som trengs for dette prosjektet var å fjerne RGB-lysdiodene og bruke de tre frigjorte pinnene som følger:

• D1 for summerens kontrollsignal (som også er koblet direkte til 5VDC strømforsyning)
• D7 for en hvit innvendig LED
• D8 for en av de blinkende fargede lysdiodene, som jeg har kalt et "disco" -lys

Selve summeren stikker pent inn under motorrommet, så det var kjapt å kjøre ledningene tilbake til NodeMCU.

Trinn 3: Oppdatere GUI

Det første trinnet i oppdateringen av GUI var å lage fire separate websider:

• En "sprutskjerm" som lanseres via et tilpasset ikon på smarttelefonen og lenker til de andre sidene
• "Kontroller" -siden som vel, styrer lysene (og nå, selvfølgelig, hornet)
• "Spill" -siden

• En oppsettside som inneholder konfigurasjonsalternativer som:

  • Slå lyden av og på
  • Angi tidssone (Mini får tid fra internett slik at den kan blinke med timene med riktig tid)
  • Justering når "autolysene" vil slå frontlysene på og av basert på lysnivået i omgivelsene
  • Tilbakestille High Score og High Scorer -navnet (lagret i EEPROM)

Å skille funksjonene på denne måten gir en mye mer app-lignende opplevelse. Å få NodeMCU til å betjene flere sider var en av utfordringene for dette prosjektet. Etter å ha prøvd et par forskjellige tilnærminger, kom jeg over koden du ser i linje 232 til 236 i hoved Arduino -skissen. Dette fungerer bra - bare opprett indeksfilen din og navngi etterfølgende sider side1, side2 osv. Jeg fant ut at jeg måtte sette alle ressursfilene (CSS og bilder) i rotdatamappen, men dette er egentlig ikke et problem for nettsteder med denne størrelsen.

Deretter måtte jeg jobbe med CSS og Javascript for å lage noe som så ut som om det tilhørte en Lego Mini. Siden jeg vet nesten ingenting om begge emnene, var det mye googling her før jeg fikk noe jeg var fornøyd med. Jeg begynte med å skamløst kopiere en CSS-stil legokloss på CodePen her. Jeg ønsket også å gå bort fra å merke knappene med tekst og ende opp med å bruke enkel grafikk fra Icons8, som var perfekte for mine formål. Resten falt på plass derfra. Sidene gjengir ganske bra på alle iPhones jeg har testet dem på. Forhåpentligvis gjelder det samme også for Android -telefoner (ser OK ut på en Chrome -nettleser på skrivebordet).

Trinn 4: Spillkoden

Kommunikasjon mellom NodeMCU -serveren og smarttelefonleseren er via Websockets. Etter at en bruker har trykket på en knapp, sender nettleseren et teksttegn til NodeMCU som tilsvarer en eller flere av Mini -lampene. Ytterligere tegn blir sendt for å kontrollere spillflyten. Arduino -koden iverksetter deretter handling basert på det mottatte tegnet. Websocket -kommunikasjon kan bare håndtere binære og teksttegn, så noen konvertering er nødvendig for heltall (f.eks. Tidssonen).

Som jeg nevnte, hadde jeg opprinnelig forventet å bruke koden fra det koblede Hackster -prosjektet for kjernespillfunksjonene. Det jeg forventet ville skje er at etter at en spiller trykket på en knapp, vil den tilhørende lysdioden lyse og koden vil gjøre en digital lesing på alle lysdiodene for å se om den riktige var tent (Hackster -prosjektet sjekker de fysiske knappene, men det er den samme ideen). Dette fungerte, liksom, men av årsaker som fremdeles er uklare for meg, ikke helt. Omtrent 10% av tiden Mini ville si at en feil knapp ble trykket på når den faktisk var den riktige. Alt virket OK basert på det jeg kunne se på den serielle skjermen og i nettleserkonsollen, så jeg aner ikke hvorfor det ikke fungerte.

Etter mye faffing med å prøve å innføre noen feilkontroll, droppet jeg hele ideen om å lese LED -tilstandene og opprettet en "svar" -matrise som sjekker om Websocket -teksten mottar tilsvarer riktig pin som er lagret i "sekvens" -matrisen som spiller lyssekvensen for å huske. Dette ser ut til å være 100% pålitelig selv om måten jeg har implementert det er litt skremmende. Etter å ha kommet med denne metoden, kom jeg på dette, som er en interessant utforskning av måten noen digitale låser fungerer på og analog med tilnærmingen som ble brukt i spillet.

Tidspunktet for knappinnganger håndteres nå med Javascript på nettlesersiden (jeg tillater veldig sjenerøse 10 sekunder mellom knappinngangene), og spillets flyt er nå helt kontrollert av spilleren i stedet for hardkodet. Displayet inneholder vinduer som viser gjenværende tid for å trykke på neste knapp og antall innganger som er igjen før sekvensen er riktig sendt av spilleren.

Høy score lagres i EEPROM (eller det som gjelder for EEPROM i ESP8266-verdenen), og hvis en spiller treffer en ny høy score, lar en popup-boks dem angi et navn de velger, som også er lagret i EEPROM. Disse verdiene kan tilbakestilles via oppsettssiden (jeg er sikker på at det kan være legitime grunner til dette).

Med alt det sagt, brukte jeg en anstendig del av Hackster-spillkoden på nytt, noe som ga ting mye fart.

Trinn 5: Resten av koden

Sammenlignet med Hackster -prosjektkoden ser min Arduino -skisse enorm ut, selv uten HTML, CSS og Javascript i datafilene. Men hoveddelen av skissen er en haug med funksjoner knyttet til grunnleggende operasjoner som å lage og administrere serveren, få NTP-tid, mDNS, sørge for oppdatering over luften, WiFi-administrasjon, SPIFFS-filbehandling og lignende.

Javascript i HTML -filene er først og fremst for håndtering av Websocket -meldingene (mottatt og sendt) og for å øke interaktiviteten til GUI.

Som jeg nevnte, ønsket jeg å forbedre funksjonaliteten til "auto lights" -funksjonen, som bruker en lysavhengig motstand på NodeMCUs eneste analoge pin for å oppdage omgivende lys og slå på Mini -lysene på et forhåndsinnstilt nivå (når den ikke er i spillmodus, selvfølgelig). Selv om dette veldig mye er en useriøs funksjon i et useriøst prosjekt, plaget det meg at jeg i det opprinnelige prosjektet hadde hardkodet oppstartsterskelen og at en bruker ikke hadde noen mulighet til å se hvordan det rådende lysnivået var knyttet til den terskelen. Nå sendes lysnivåavlesningen til oppsettssiden hvert femte sekund, og den siden viser også gjeldende terskler for å slå på og av (som kan konfigureres av brukeren). Så jobben er gjort med den.

Å, glemte nesten. Koden er på GitHub her. Etter nedlasting legger du hele pakken i en ny mappe, laster opp Arduino -skissen og deretter innholdet i datamappen til SPIFFS.