Lego Mini Memory Game: 5 trin (med billeder)

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:28

For et år siden skrev jeg en Instructable om at installere en flok lysdioder i en Lego Mini Cooper. Innovationen, som den var, var, at lysdioderne kunne styres med en smartphone (eller via en hvilken som helst webbrowser, for den sags skyld).

Som jeg møjsommeligt beskrev i den Instructable, var det meste af indsatsen dengang relateret til tilslutning af Mini, uden at det hele gik i stykker. Lidt til min overraskelse overlevede Mini efterfølgende en tur fra Connecticut til Toronto og har arbejdet mere eller mindre siden.

"Hvis det ikke var ødelagt, fikser han det, indtil det var" vil i bedste fald være min epitaf, så da Mini vendte hjem til jul, var det tid til Lego Mini 2.0. Når alt kommer til alt, hvis Tesla kan skubbe softwareopdateringer til sine biler, hvor svært kan det så være?

Jeg havde et par ideer:

• Forbedre den ret uklare brugergrænseflade
• Tilføj et horn!
• Forbedre funktionen "autolys"; og, vigtigst
• Tilføj en spilfunktion (selv jeg erkendte, at nyheden med at tænde og slukke Mini's lys med din telefon ville falde før eller siden)

Spilfunktionen var den største opgave, ikke mindst fordi det ikke umiddelbart var indlysende for mig, hvilken slags spil det kunne være. Mini er alt for skrøbelig til at opretholde et spil, der involverer den, der skal håndteres (undtagen muligvis en deprimerende variant af Jenga). En anden hindring var, at jeg aldrig har programmeret et spil i mit liv.

Efter et års frugtløs grublering faldt jeg over et projekt på Hackster, hvor en Arduino Uno bruges til at efterligne et hukommelsesspil, der stammer fra 1970'erne, kaldet Simon. I en nøddeskal spillede Simon -enheden en række lys, som spilleren derefter skulle huske og afspille ved at trykke på knapper. Efter hver vellykkede runde blev sekvensen forøget i længden.

På trods af at den var den nødvendige årgang, havde jeg faktisk aldrig hørt om dette spil, og jeg må sige, at det er forbløffende, hvad der gik til morskab tilbage på dagen. Endnu mere fantastisk er, at Simon -spillet stadig er til salg og får strålende anmeldelser på Amazon. Det var klart, at dette skulle være den primære kandidat til at tilpasse mig mine formål. Tross alt havde Mini allerede lysene, så alt hvad jeg skulle gøre var at droppe de fysiske knapper og få brugerindgang leveret via en smartphone. På softwaresiden syntes det derfor stort set bare at være et klipp-og-indsæt-job.

Men først skulle jeg foretage nogle mindre ændringer af hardwaren.

Trin 1: Komponenter, værktøjer og ressourcer

Hvis du replikerer dette projekt med en Lego Mini, skal du bruge alle de ting, der er angivet i min tidligere Instructable. Det eneste ekstra du skal bruge er en passiv summer, som bruges til hornet og til at lave en masse irriterende lyde under spillet (som kan deaktiveres).

Som det vil blive klart, når man diskuterer softwaren, er der ikke noget reelt behov for at bruge en Lego Mini til spillet. Du kan bruge et andet Lego -kit eller faktisk en flok lysdioder på et brødbræt, der er tilsluttet ethvert ESP8266 -udviklingsbræt. Med nogle relæer kan du endda bruge dit hjems rumbelysning. Børn, spørg dog først dine forældre om det.

Tilsvarende er der ikke behov for yderligere værktøjer eller ressourcer ud over dem, der er angivet til det originale projekt.

Hvis du er blandt de håndfulde mennesker, der læser den originale projektbeskrivelse, ved du, at Lego Mini oprindeligt blev købt som en gave til min voksne datter, der har en næsten identisk "rigtig" Mini eller næsten identisk med det kan gives, at det er en ny mini, ikke en "klassiker". Manglen på nogen meningsfulde ekstra komponenter gjorde dette nye projekt endnu mere attraktivt, da det ville gøre det muligt for mig at re-gave Lego Mini 2.0 som en ny julegave uden at koste knap en krone. Geni!

Trin 2: Hardwareændring

Det originale projekt havde individuelt styrbare RGB -indvendige lysdioder. Disse forbrugte tre ben på NodeMCU, som jeg brugte som udviklingskortet. Efter diskret samråd med Lego Mini -ejeren blev det fastslået, at RGB -lysdioderne var en underudnyttet funktion. Dette var vigtig intelligens, fordi jeg havde brug for at frigøre en nål til summeren/hornet.

Ovenstående kredsløbsdiagram er fra det originale projekt. Den eneste ændring, der var nødvendig for dette projekt, var at fjerne RGB-lysdioderne og bruge de tre frigjorte stifter som følger:

• D1 for summerens kontrolsignal (som også er forbundet direkte til 5VDC strømforsyningen)
• D7 til en hvid indvendig LED
• D8 for en af de blinkende farvede LED'er, som jeg har døbt et "diskotek" lys

Selve summeren stikker pænt væk under motorrummet, så det var hurtigt at køre ledningerne tilbage til NodeMCU.

Trin 3: Opdatering af GUI

Det første trin i opdateringen af GUI var at oprette fire separate websider:

• En "stænkskærm", der starter via et brugerdefineret ikon på din smartphone og linker til de andre sider
• "Controls" -siden, der godt kontrollerer lysene (og nu selvfølgelig hornet)
• Siden "Spil"

• En opsætningsside, der indeholder konfigurationsmuligheder såsom:

  • Slå lyden til og fra
  • Indstilling af tidszonen (Mini får tid fra internettet, så den kan blinke sine lamper på timen med det relevante tidspunkt)
  • Justering af hvornår "autolys" vil tænde og slukke forlygterne baseret på det omgivende lysniveau
  • Nulstilling af High Score og High Scorer navn (gemt i EEPROM)

At adskille funktionerne på denne måde giver en meget mere app-lignende oplevelse. At få NodeMCU til at betjene flere sider var en af udfordringerne for dette projekt. Efter at have prøvet et par forskellige tilgange, stødte jeg på den kode, du ser i linje 232 til 236 i den vigtigste Arduino -skitse. Dette fungerer godt - bare opret din indeksfil og navngiv derefter efterfølgende sider side1, side2 osv. Jeg fandt ud af, at jeg var nødt til at lægge alle ressourcefiler (CSS og billeder) i roddatamappen, men dette er ikke rigtig et problem for websteder med denne størrelse.

Dernæst måtte jeg arbejde med CSS og Javascript for at lave noget, der lignede, at det tilhørte en Lego Mini. Da jeg ved næsten ingenting om begge emner, var der meget Googling her, før jeg fik noget, jeg var glad for. Jeg startede med at skamløst kopiere en CSS-stilet legoklods på CodePen her. Jeg ville også væk fra at mærke knapperne med tekst og ende med at bruge simpel grafik fra Icons8, som var perfekte til mine formål. Resten faldt på plads derfra. Siderne gengives ret godt på alle iPhones, jeg har testet dem på. Forhåbentlig gælder det samme også for Android -telefoner (ser OK ud på en Chrome -browser på skrivebordet).

Trin 4: Spilkoden

Kommunikation mellem NodeMCU -serveren og smartphone -browseren sker via Websockets. Efter at en bruger har trykket på en knap, sender browseren et teksttegn til NodeMCU, der svarer til en eller flere af Mini -lamperne. Yderligere tegn sendes for at kontrollere spilforløbet. Arduino -koden tager derefter handling baseret på det modtagne tegn. Websocket -kommunikation kan kun håndtere binære og teksttegn, så en vis konvertering er nødvendig for heltal (f.eks. Tidszonen).

Som jeg nævnte, havde jeg oprindeligt forventet at bruge koden fra det linkede Hackster -projekt til kernespilfunktionerne. Det, jeg forventede, ville ske, er, at efter at en spiller har trykket på en knap, vil den tilsvarende LED lyse, og koden vil gøre en digitalRead på alle lysdioderne for at se, om den rigtige er tændt (Hackster -projektet kontrollerer de fysiske knapindgange, men det er den samme idé). Dette virkede, sådan set, men af grunde, der stadig er uklare for mig, ikke perfekt. Omkring 10% af tiden ville Mini sige, at der blev trykket på en forkert knap, når den faktisk var den rigtige. Alt virkede OK baseret på, hvad jeg kunne se i den serielle skærm og i browserkonsollen, så jeg aner ikke, hvorfor det ikke virkede.

Efter en masse bøvl med at forsøge at indføre en fejlkontrol, droppede jeg hele tanken om at læse LED -tilstande og oprettede et "svar" -array, der kontrollerer, om Websocket -teksten modtog svarer til den korrekte pin gemt i "sekvens" -arrayet, der spiller lyssekvensen for at huske. Dette ser ud til at være 100% pålideligt, selvom den måde, jeg har implementeret det, er lidt plodende. Efter at have fundet på denne metode, faldt jeg over dette, hvilket er en interessant udforskning af den måde, nogle digitale låse fungerer på og analog med den tilgang, der blev brugt i spillet.

Tidspunktet for knapindgange håndteres nu med Javascript på browsersiden (jeg tillader meget generøse 10 sekunder mellem knapindgange), og spillets flow er nu helt kontrolleret af spilleren frem for hårdt kodet. Displayet indeholder vinduer, der viser den resterende tid til at trykke på den næste knap, og antallet af input, der er tilbage, før sekvensen er korrekt indsendt af spilleren.

Høj score gemmes i EEPROM (eller hvad der gælder for EEPROM i ESP8266-verdenen), og hvis en spiller rammer en ny høj score, giver en pop-up-boks dem mulighed for at indtaste et navn, de vælger, som også er gemt i EEPROM. Disse værdier kan nulstilles via opsætningssiden (jeg er sikker på, at der kan være legitime årsager til dette).

Med alt det sagt genbrugte jeg en anstændig del af Hackster-spilkoden, hvilket fremskyndede tingene meget.

Trin 5: Resten af koden

Sammenlignet med Hackster -projektkoden ser min Arduino -skitse enorm ud, selv uden al HTML, CSS og Javascript i datafilerne. Men hovedparten af skitsen er en flok funktioner, der vedrører grundlæggende operationer som at oprette og administrere serveren, få NTP-tid, mDNS, sørge for opdatering over luften, WiFi-administration, SPIFFS-filhåndtering og lignende.

Javascript i HTML -filerne er primært til håndtering af Websocket -meddelelser (modtaget og sendt) og øget interaktiviteten af GUI.

Som jeg nævnte, ville jeg forbedre funktionaliteten af funktionen "auto lights", som bruger en lysafhængig modstand på NodeMCU's eneste analoge pin til at registrere omgivende lys og tænde Mini's lys på et forudindstillet niveau (når det ikke er i spiltilstand), selvfølgelig). Selvom dette i høj grad er en useriøs funktion i et useriøst projekt, generede det mig, at jeg i det originale projekt havde hårdkodet tændtærsklen, og at en bruger ikke havde nogen måde at se, hvordan det herskende lysniveau relaterede til denne tærskel. Nu sendes lysniveauaflæsning til opsætningssiden hvert femte sekund, og siden viser også de aktuelle tærskler for tænd og sluk (som kan konfigureres af brugeren). Så arbejdet udført på den ene.

Åh, glemte næsten. Koden er på GitHub her. Efter download skal du lægge hele pakken i en ny mappe, uploade Arduino -skitsen og derefter indholdet af datamappen til SPIFFS.