Lego Mini Memory Game: 5 steg (med bilder)

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:45

För något år sedan skrev jag en Instructable om att installera ett gäng lysdioder i en Lego Mini Cooper. Innovationen, som den var, var att lysdioderna kunde styras med en smartphone (eller via vilken webbläsare som helst).

Som jag mödosamt beskrev i den instruerbara delen, anslöt det mesta av ansträngningarna då till att koppla upp Mini utan att det hela gick sönder. Något till min förvåning överlevde Mini sedan en resa från Connecticut till Toronto och har fungerat, mer eller mindre, sedan dess.

"Om det inte var trasigt, fixade han det tills det var" blir min epitaf, i bästa fall, så när Mini kom hem till jul var det dags för Lego Mini 2.0. När allt kommer omkring, om Tesla kan driva programuppdateringar till sina bilar, hur svårt kan det vara?

Jag hade några idéer:

• Förbättra det ganska klumpiga användargränssnittet
• Lägg till ett horn!
• Förbättra funktionen "autoljus"; och, viktigast
• Lägg till en spelfunktion (även jag insåg att nyheten att tända och stänga av Mini -lamporna med din telefon kommer att blekna förr eller senare)

Spelfunktionen var den största uppgiften, inte minst för att det inte direkt var uppenbart för mig vilken typ av spel det kunde vara. Mini är alldeles för bräcklig för att upprätthålla ett spel som innebär att den hanteras (förutom möjligen en deprimerande variant av Jenga). Ett annat hinder var att jag aldrig har programmerat ett spel i mitt liv.

Efter ett år av fruktlös fundering, snubblade jag över ett projekt på Hackster, där en Arduino Uno används för att efterlikna en minnesspelleksak från 1970 -talet som heter Simon. I ett nötskal spelade Simon -enheten upp en serie ljus som spelaren sedan var tvungen att komma ihåg och spela upp genom att trycka på knapparna. Efter varje lyckad omgång ökades sekvensen i längd.

Trots att jag var av erforderlig årgång hade jag faktiskt aldrig hört talas om det här spelet, och jag måste säga att det är fantastiskt vad som gick för nöjen tillbaka på dagen. Ännu mer häpnadsväckande är att Simon -spelet fortfarande säljs och får fantastiska recensioner på Amazon. Tydligen måste detta vara den främsta kandidaten för att anpassa mig för mina syften. När allt kommer omkring hade Mini redan lamporna, så allt jag behövde göra var att släppa de fysiska knapparna och få användarinmatning via en smartphone. På programvarusidan tycktes det därför i stort sett bara vara ett klipp-och-klistra-jobb.

Men först behövde jag göra några mindre ändringar av hårdvaran.

Steg 1: Komponenter, verktyg och resurser

Om du replikerar detta projekt med en Lego Mini, behöver du alla saker som anges i min tidigare Instructable. Det enda extra du behöver är en passiv summer, som används för hornet och för att göra en massa irriterande ljud under spelet (som kan inaktiveras).

Som kommer att bli klart när man diskuterar programvaran, det finns inget riktigt behov av att använda en Lego Mini för spelet. Du kan använda ett annat Lego -kit, eller ett gäng lysdioder på en bräda som är ansluten till alla ESP8266 -utvecklingsbrädor. Med några reläer kan du till och med använda ditt hems rumsbelysning. Barn, fråga dina föräldrar först om det dock.

På samma sätt behövs inga ytterligare verktyg eller resurser utöver de som anges för det ursprungliga projektet.

Om du är bland en handfull människor som läser den ursprungliga projektbeskrivningen vet du att Lego Mini ursprungligen köptes som en present till min vuxna dotter, som har en nästan identisk "riktig" Mini, eller så nästan identisk som det kan ges att det är en ny mini, inte en "klassiker". Avsaknaden av några meningsfulla tilläggskomponenter gjorde detta nya projekt ännu mer attraktivt eftersom det skulle göra det möjligt för mig att effektivt presentera Lego Mini 2.0 som en ny julklapp utan att det kostar knappt en krona. Geni!

Steg 2: Hårdvarumodifiering

Det ursprungliga projektet hade individuellt kontrollerbara RGB -LED -lampor. Dessa förbrukade tre stift på NodeMCU, som jag använde som utvecklingskort. Efter diskret samråd med Lego Mini -ägaren bestämdes det att RGB -lysdioderna var en underanvänd funktion. Detta var viktig intelligens eftersom jag behövde frigöra en nål för summern/hornet.

Ovanstående kretsschema är från det ursprungliga projektet. Den enda förändringen som behövs för detta projekt var att ta bort RGB-lysdioderna och använda de tre frigjorda stiften enligt följande:

• D1 för summerns styrsignal (som också är ansluten direkt till 5VDC strömförsörjning)
• D7 för en vit inre LED
• D8 för en av de blinkande färgade lysdioderna, som jag har kallat ett "disco" -ljus

Själv summer summerar snyggt under motorrummet så att köra ledningarna tillbaka till NodeMCU var ett ögonblick.

Steg 3: Uppdatera GUI

Det första steget i uppdateringen av GUI var att skapa fyra separata webbsidor:

• En "stänkskärm" som startas via en anpassad ikon på din smartphone och länkar till de andra sidorna
• Sidan "Kontroller" som, väl, styr lamporna (och nu, naturligtvis, hornet)
• "Spel" -sidan

• En konfigurationssida som innehåller konfigurationsalternativ som:

  • Slå på och av ljudet
  • Ställa in tidszonen (Mini får tid från internet så att den kan blinka i timmen med rätt tid)
  • Justera när "autolamporna" tänder och släcker strålkastarna baserat på omgivande ljusnivå
  • Återställer High Score och High Scorer -namnet (lagras i EEPROM)

Att separera funktionerna på detta sätt ger en mycket mer appliknande upplevelse. Att få NodeMCU att betjäna flera sidor var en av utmaningarna för detta projekt. Efter att ha provat ett par olika tillvägagångssätt stötte jag på koden som du ser i raderna 232 till 236 i den huvudsakliga Arduino -skissen. Detta fungerar bra - skapa bara din indexfil och namnge efterföljande sidor page1, page2 etc. Jag tyckte att jag var tvungen att lägga alla resursfiler (CSS och bilder) i rotdatamappen men det här är egentligen inte ett problem för webbplatser med denna storlek.

Därefter fick jag jobba med CSS och Javascript för att göra något som såg ut att tillhöra en Lego Mini. Eftersom jag inte vet någonting om något av ämnena var det mycket Googling här innan jag fick något jag var nöjd med. Jag började med att skamlöst kopiera en CSS-stil lego tegel på CodePen här. Jag ville också gå bort från att märka knapparna med text och sluta använda enkel grafik från Icons8, som var perfekta för mina syften. Resten föll på plats därifrån. Sidorna gör ganska bra på alla iPhones jag testat dem på. Förhoppningsvis gäller detsamma även för Android -telefoner (ser OK ut på en stationär Chrome -webbläsare).

Steg 4: Spelkoden

Kommunikation mellan NodeMCU -servern och smartphone -webbläsaren sker via Websockets. Efter att en knapp har tryckts av användaren skickar webbläsaren ett texttecken till NodeMCU som motsvarar en eller flera av Mini -lamporna. Ytterligare karaktärer skickas för att kontrollera spelflödet. Arduino -koden vidtar sedan åtgärder baserat på den mottagna karaktären. Websocket -kommunikation kan bara hantera binära och texttecken så viss konvertering behövs för heltal (t.ex. tidszonen).

Som jag nämnde hade jag ursprungligen förväntat mig att använda koden från det länkade Hackster -projektet för kärnfunktionerna. Vad jag förväntade mig skulle hända är att efter att en spelare tryckt på en knapp tänds motsvarande lysdiod och koden gör en digital läsning på alla lysdioder för att se om den rätta var tänd (Hackster -projektet kontrollerar de fysiska knapparna, men det är samma idé). Detta fungerade, liksom, men av skäl som fortfarande är oklara för mig, inte perfekt. Ungefär 10% av tiden skulle Mini säga att en felaktig knapp trycktes in när den faktiskt var rätt. Allt verkade OK baserat på vad jag kunde se i seriell bildskärm och i webbläsarkonsolen så jag har ingen aning om varför det inte fungerade.

Efter mycket tjafs med att försöka införa lite felkontroll, släppte jag hela idén med att läsa LED -tillstånden och skapade en "svar" -matris som kontrollerar om Websocket -texten mottog motsvarar den korrekta stift som lagras i "sekvens" -matrisen som spelar ljussekvensen att komma ihåg. Detta verkar vara 100% tillförlitligt även om sättet jag har implementerat det är lite tjatigt. Efter att ha kommit fram till den här metoden kom jag på det här, vilket är en intressant undersökning av hur vissa digitala lås fungerar och analogt med den metod som används i spelet.

Tidpunkten för knappinmatningar hanteras nu med Javascript på webbläsarens sida (jag tillåter mycket generösa 10 sekunder mellan knappinsignaler) och spelets flöde styrs nu helt av spelaren snarare än hårdkodad. Displayen innehåller fönster som visar återstående tid för nästa knapptryckning och antalet ingångar som återstår innan sekvensen skickas korrekt av spelaren.

Hög poäng lagras i EEPROM (eller vad som gäller för EEPROM i ESP8266-världen) och om en spelare träffar en ny hög poäng kan en popup-ruta låta dem ange ett namn de väljer, vilket också lagras i EEPROM. Dessa värden kan återställas via inställningssidan (jag är säker på att det kan finnas legitima skäl till detta).

Med allt detta återanvände jag en anständig del av Hackster-spelkoden som påskyndade saker mycket.

Steg 5: Resten av koden

Jämfört med Hackster -projektkoden ser min Arduino -skiss enorm ut, även utan HTML, CSS och Javascript i datafilerna. Men huvuddelen av skissen är ett gäng funktioner relaterade till grundläggande operationer som att skapa och hantera servern, få NTP-tid, mDNS, tillhandahålla över-the-air-uppdatering, WiFi-hantering, SPIFFS-filhantering och liknande.

Javascript i HTML -filerna är främst för att hantera Websocket -meddelanden (mottagna och skickade) och öka interaktiviteten för GUI.

Som jag nämnde ville jag förbättra funktionen för "auto lights" -funktionen, som använder ett ljusberoende motstånd på NodeMCU: s enda analoga stift för att upptäcka omgivande ljus och tända Mini -lamporna på en förinställd nivå (när den inte är i spelläge, självklart). Även om detta är mycket lättsinnigt i ett lättsinnigt projekt, störde det mig att jag i det ursprungliga projektet hade hårdkodat startgränsen och att en användare inte hade något sätt att se hur den rådande ljusnivån relaterade till den tröskeln. Nu skickas ljusnivåavläsningen till inställningssidan var femte sekund och den sidan visar också de aktuella trösklarna för att slå på och stänga av (som kan konfigureras av användaren). Så jobbet gjort med den.

Åh, glömde nästan. Koden finns på GitHub här. Efter nedladdning lägger du hela paketet i en ny mapp, laddar upp Arduino -skissen och sedan innehållet i datamappen till SPIFFS.