Förra veckan byggde jag en LED-kub Hur man gör en pulserande Arduino LED-kub som ser ut som den kom från framtiden Hur man gör en pulserande Arduino LED-kub som ser ut som den kom från framtiden Om du har dabbled med några nybörjare Arduino-projekt, men letar efter något lite permanent och på en helt annan nivå av häftigt, då är den ödmjuka 4 x 4 x 4 LED-kuben ... Läs mer - 64 lysdioder som du kan programmera för att göra fantastiska futuristiska ljusutställningar - och jag hoppas du gjorde det, för det är ett bra projekt att motivera dig och utöka din Arduino skillset. Jag lämnade dig med några grundläggande appar för att få dig att tänka, men idag presenterar jag några fler bitar av programvara som jag gjorde för kuben, tillsammans med kodförklaringar. Syftet med detta är att ge dig några mer vackra lightshows att springa, men också för att lära dig om några av begränsningarna att programmera kuben och lära dig några nya programmeringskoncept i processen.
Detta är en ganska avancerad kodning; du behöver verkligen läsa alla mina tidigare Arduino-handledning och vår nybörjares Arduino-guide innan du anpassar koden som tillhandahålls.
App 1: Mini Snake
I stället för att köra en uppsättning orm-liknande mönster-sekvens, ville jag programmera en orm - en artificiell som skulle göra det egna slumpmässiga val och vara helt oförutsägbar. Den är begränsad till endast 2 segment, vilket jag kommer att förklara senare, och du kan se demoen nedan. Ladda ner hela koden här.
När du arbetar med 3D-utrymme behöver du 3 koordinater för en enda punkt: X, Y och Z.
I vår kub representeras X och Z-planen av LED-stiften, medan Y är direkt mappad till katodplanen. För att underlätta arbetet med dessa koordinater och räkna ut rörelsen runt kuben skapade jag därför en ny datatyp (med hjälp av struct) för att representera en enda punkt på kuben - som jag kallade "xyz". Den består av bara två heltal: "xz" och "y". Med denna struktur kan jag då också representera en riktning, som anges nedan i vårt speciella (xz, y) koordinatsystem:
Y-rörelse (uppåt, nedåt) : (xz, y + 1), (xz, y-1)
Z- rörelse (framåt, bakåt) : (xz-1, y), (xz + 1, y)
X-rörelse (vänster, höger) : (xz + 4, y), (xz-4, y)
Till exempel, för att flytta lysdioden i läge (0, 0) en till vänster, tillämpar vi (xz + 4, y) och hamnar med (0, 4) .
Det finns vissa gränser som placeras på rörelse - nämligen att Y-koordinater endast kan vara möjliga 0 till 3 (0 är bottenskiktet, 3 är toppen) och XZ-koordinaterna kan endast vara 0 till 15 . En ytterligare gräns placeras på Z-rörelsen för att förhindra att "hoppar" från baksidan till kubens framsida och vice versa. I det här fallet använder vi modulfunktionen för att testa för multiplar av 4 och förneka det rörelseförsöket. Detta är logik representeras i den giltiga () -funktionen, som returnerar en sant om den föreslagna riktningen är ett acceptabelt drag och falskt annars. Jag har lagt till en ytterligare funktion för att söka efter en inverterad riktning - det vill säga om ormen går i en riktning, vill vi inte att den ska gå bakåt på sig själv, även om det annars är en giltig plats att flytta till - och en move () -funktionen, som tar en koordinat, en riktning och returnerar den nya koordinaten.
Funktionerna XYZ datatyp, valid (), move () och inverse () kan alla hittas i xyz.h- filen i hämtningarna. Om du undrar varför det här placerades i en separat fil i stället för huvudprogramfilen, beror det på några komplicerade Arduino-compilerregler som hindrar funktioner från att returnera anpassade datatyper . De måste placeras i sin egen fil och importeras sedan i början av huvudfilen.
Tillbaka i den huvudsakliga runtime-filen lagras en rad riktningar alla möjliga rörelser som ormen kan göra; vi kan helt enkelt välja en slumpmässig array medlem för att få en ny riktning. Variabler skapas också för att lagra aktuell plats (nu), tidigare riktning och tidigare plats . Resten av koden ska vara ganska uppenbar för dig; bara f o r slingor, och släcka och släcka lysdioder. I huvudslingan kontrollerar vi för att se om den föreslagna riktningen är giltig, och om det är så går vi så. Om inte, väljer vi en ny riktning.
Det enda som ska påpekas i huvudslingan är några kontroller för att rätta till en bugg som jag hittade med multiplexing: om den nya platsen var på samma katodplan eller samma anodstift, skulle det leda till att båda utgåvorna stängdes av tidigare LED. Det är också vid denna tidpunkt att jag insåg att gå utöver ett 2-segment orm skulle bli omöjligt med mitt nuvarande genomförande: försök att tända 3 lysdioder i ett hörnarrangemang. Du kan inte, för med 2 lager och 2 LED-stift aktiverade, skulle 4 LED-lampor slås på, inte 3. Detta är ett inneboende problem med vår begränsade multiplexade kubdesign, men inte oroa dig: vi behöver helt enkelt använda kraften av uthållighet av syn att skriva om teckningsmetoden.
Persistens av vision innebär att när ljus når våra ögon i följd - snabbare än vi kan bearbeta det - verkar det vara en enda bild. I vårt fall, i stället för att rita alla fyra skikten samtidigt, borde vi rita den första, avaktivera den, dra den andra och avaktivera den: Snabbare än vi kan berätta några förändringar sker till och med. Det här är principen om vilka meddelandeskrivare som arbetar, som den här:
Ny teckningsmetod som använder persistens av vision
Först då, en ny rita rutin. Jag har skapat en 4 x 16 tvådimensionell uppsättning bitar (sant eller falskt) för att vara en bokstavlig representation av läget för LED-kuben. Rita rutinen kommer att genomföra persistens av syn genom att helt enkelt iterera över detta och spola ut varje lager till kuben för ett kort ögonblick. Det fortsätter att rita sig i det nuvarande läget tills uppdateringstiden har gått, vid vilken tidpunkt kommer vi att skicka kontrollen tillbaka till huvudslingan (). Jag har sparat den här delen av koden i denna LED_cube_POV-fil, så om du bara vill hoppa in i programmering dina egna spel och så är du välkommen att använda den som en bas.
App 2: Livets lek
För nu, låt oss utveckla detta till en grundläggande version av Conways Game of Life. För de av er som är obekanta (försök med Googling att hitta en fantastisk påskäggsanimation), är Game of Life ett exempel på cellulär automat som skapar ett fascinerande mönster av framväxande beteende, som endast ges några enkla regler.
http://www.youtube.com/watch?v=XcuBvj0pw-E
Det här är till exempel hur myror verkar flytta med intelligens och bikopsinne, trots det biologiska faktum att de faktiskt bara följer väldigt grundläggande hormonella regler. Här är den fullständiga koden för nedladdning: Tryck på återställningsknappen för att starta om. Om du befinner dig i samma mönster om och om igen, försök hålla ner vilopnappen längre.
http://www.youtube.com/watch?v=iBnL8pulJ
Här är spelets livsregler:
- Alla levande celler med färre än två levande grannar dör, som om de orsakas av underbefolkningen.
- En levande cell med två eller tre levande grannar lever vidare till nästa generation.
- Vilken levande cell som helst med mer än tre levande grannar dör, som genom överbeläggning.
- Varje dödcell med exakt tre levande grannar blir en levande cell, som genom reproduktion.
Kör koden. Du kommer att märka inom 5 till 10 "generationer", automatiken har förmodligen kommit vila, stabiliserar i en viss position; Ibland kommer det här stabila mönstret att byta plats och växla runt ombord. I sällsynta fall kan de till och med ha helt dött ut. Det här är en begränsning att bara ha 4x4x4-lysdioder att arbeta med, men det är en bra inlärningsövning ändå.
Förklara koden:
- Du kanske inte känner till funktionen memcpy () . Jag har använt detta för att spara det tidigare speltillståndet, eftersom arrays inte bara kan tilldelas varandra som vanliga variabler - du måste faktiskt kopiera över minnesutrymmet (i detta fall 64 bitar).
- funktionen howManyNeighbours () ska vara självförklarande, men om det inte är det, använder den här metoden en enda koordinat och går genom varje eventuell granne (samma uppsättning riktningar som vi tidigare använde i ormapp) för att kontrollera om de är giltiga . Det kontrollerar då om de andra LED-lamporna var "på" i föregående speltillstånd och räknar med hur många som finns.
- Huvudfunktionen för denna Game of Life-app är progressGame (), som tillämpar automatreglerna till det aktuella speltillståndet.
Förbättringar : Jag har tillbringat alltför länge på det här hittills, men du kanske vill försöka lägga till i en check som automatiskt återställer brädan efter 5 eller så generationer av samma mönster. vänligen meddela mig det! Jag föreslår också att man försöker lägga till POV-metoden till ormspelet för att förhoppningsvis göra en längre orm möjlig.
Det är det från mig idag. Jag kan återkomma några fler Arduino LED-kubprogram på senare tid, men förhoppningsvis borde du kunna ändra min kod och skapa egna spelregler: Låt oss veta vad du kommer med i kommentarerna, så vi kan alla ladda ner dina skapelser! Som alltid kommer jag att vara här för att svara på dina frågor och försvara mina fasansfulla kodningsförmågor.
Bildkredit: Kartesiska koordinater - Wikimedia-användare Sakurambo