For et par uker siden brukte vi : de bygde et rom, som de fylte med smarte enheter og lanserte en YouTube-sending fra det. Spillere kunne kontrollere IoT-enheter fra spillnettstedet; Målet var å finne et våpen gjemt i rommet (en kraftig laserpeker), hacke det og forårsake kortslutning i rommet.
For å legge til handlingen, plasserte vi en makuleringsmaskin i rommet, der vi lastet 200 000 rubler: makuleringsmaskinen spiste en regning i timen. Etter å ha vunnet spillet, kan du stoppe makuleringsmaskinen og ta alle de gjenværende pengene.
Vi har allerede fortalt Og prosjekt. Det er på tide å snakke om maskinvaren og hvordan den ble satt sammen.
Det var mange forespørsler om å vise øyeblikket for rengjøring av et rom - vi viser hvordan vi tar det fra hverandre
Maskinvarearkitektur: Romkontroll
Vi begynte å designe en maskinvareløsning da scenariet allerede var noenlunde forstått, backend var klar, og vi hadde et tomt rom klar til å installere utstyret.
Når vi husker den gamle vitsen "The S in IoT står for Security" ("Bokstaven S i IoT-forkortelsen står for Security"), bestemte vi oss for at denne gangen samhandler spillerne i spillscenarioet kun med front-end og back-end av stedet, men får ikke mulighet til å komme direkte til jernet.
Dette ble gjort av sikkerhetshensyn og av hensyn til det som skjedde på skjermen: med direkte tilgang til maskinvaren av spillere, ville det være mye vanskeligere å isolere sikre og potensielt farlige handlinger, for eksempel rask rulling av en makuleringsmaskin eller kontroll pyroteknikk.
Før vi startet designet, formulerte vi flere prinsipper for å kontrollere spillenheter, som ble grunnlaget for designet:
Ikke bruk trådløse løsninger
Hele spilleplassen er i én ramme, og hvert hjørne kan nås. Det var ikke noe reelt behov for trådløse tilkoblinger, og de ville ganske enkelt bli et annet feilpunkt.
Ikke bruk noen spesielle smarthusenheter
Hovedsakelig for tilpasningsfleksibilitetens skyld. Det er klart at vi kan tilpasse mange boksede versjoner av smarthussystemer med ferdige admin og kontroller for oppgaven vår, men lønnskostnadene vil være sammenlignbare med å lage din egen enkle løsning.
I tillegg var det nødvendig å komme opp med enheter som tydelig skulle vise at det var spillerne som endret tilstanden: de skrudde den på/av eller satte et spesifikt lys på bokstavene FALCON.
Vi samlet alle elementene fra offentlig tilgjengelig maskinvare som kan kjøpes i vanlige radiodelerbutikker: mellom levering av pizza og dietcola kom kurerene Chip og Dip og Leroy stadig til nettstedet.
Valget om å sette sammen alt selv forenklet feilsøking, skalerbarhet krevde imidlertid større forsiktighet under installasjonen.
Alle reléer og arudin skal ikke være synlig i rammen
Vi bestemte oss for å bringe alle de kontrollerbare elementene på ett sted og gjemme dem bak kulissene for å kunne overvåke ytelsen deres og, om nødvendig, forsiktig krype ut av syne av kameraet og erstatte den mislykkede enheten.
Til slutt ble alt skjult under bordet, og kameraet ble installert slik at ingenting var synlig under bordet. Dette var vår "blindsone" for ingeniøren å krype opp
Som et resultat fikk vi faktisk en smart enhet: den mottok tilstanden til hver av delene fra backend og endret den med den riktige kommandoen.
Fra et maskinvareimplementeringssynspunkt kontrollerte denne enheten 6 elementer:
- Flere bordlamper, de har på/av-tilstand og styres av spillere
- Bokstaver på veggen, de kan endre farge på kommando av spillerne
- Vifter som snurrer og åpner flipover når serveren er under belastning
- Laserstyrt via PWM
- Makuleringsmaskin som spiste penger etter planen
- En røykmaskin som gikk av før hvert laserskudd
Tester en røykmaskin med laser
Senere ble det lagt til et scenelys, som sto bak rammen og ble styrt akkurat som lampene fra punkt 1. Scenelyset fungerte i to tilfeller: det belyste laseren når det ble satt på den, og det belyste vekten før laser ble lansert i kampmodus.
Hva var denne smartenheten?
Hele veien prøvde Yura, maskinvarefyren vår å ikke komplisere ting og komme opp med den enkleste, minimalistiske løsningen som er mulig.
Det ble antatt at VPS ganske enkelt ville kjøre et skript som mottar json med statusen til enhetene og sender det til Arduino koblet via USB.
Koblet til portene:
- 16 vanlige stafetter (det var de som laget klikkelyden som ble hørt i videoen. Vi valgte dem hovedsakelig på grunn av denne lyden)
- 4 solid state-reléer for å kontrollere PWM-kanaler, for eksempel vifter,
- separat PWM-utgang for laser
- utgang som genererer et signal til LED-stripen
Her er et eksempel på en json-kommando som kom til reléet fra serveren
{"power":false,"speed":0,"period":null,"deviceIdentifier":"FAN"}Og dette er et eksempel på en funksjon som kommandoen kom til Arudino med
def callback(ch, method, properties, body):
request = json.loads(body.decode("utf-8"))
print(request, end="n")
send_to_serial(body)For å spore øyeblikket da laseren endelig brenner gjennom tauet og vekten flyr inn på akvariet, laget vi en liten knapp som ble utløst da vekten falt og ga et signal til systemet.
Knapp for å overvåke vektens bevegelse
Ved dette signalet skulle røykbomber laget av pingpongballer lyse opp. Vi satte 4 røykbluss direkte inn i serverkassen og koblet dem sammen med en nikrom tråd, som skulle varmes opp og fungere som en tenner.
Hus med røykbomber og kinesisk krans
Arduino
I følge den opprinnelige planen fant to handlinger sted på Arduino.
Først, når en ny forespørsel ble mottatt, ble forespørselen analysert ved hjelp av ArduinoJson-biblioteket. Deretter ble hver administrerte enhet sammenlignet med de to egenskapene:
- strømtilstand "på" eller "av" (standardtilstand)
- perioden enheten er slått på - tiden i mikrosekunder fra starten av brettet, når det er på tide å slå det av, det vil si bringe tilstanden til standard
Sist gang den ble satt ved mottak av tilsvarende parameter i JSON, men den kunne ikke overføres, ble verdien satt til 0 og ingen tilbakestilling skjedde.
Den andre handlingen som Arduino utførte hver syklus var å oppdatere tilstander, det vil si å sjekke om det var behov for å slå på noe eller om det var på tide å slå av en enhet.
Laserpeker - den samme Megatron 3000
Dette er en vanlig LSMVR450-3000MF 3000mW 450nm manuell fokus laserskjærings- og markeringsmodul.
Bokstaver Falcon
De ble laget veldig enkelt - vi kopierte ganske enkelt bokstavene fra logoen, klippet dem ut av papp og dekket dem deretter med LED-tape. I dette tilfellet måtte jeg lodde tapebitene sammen, 4 kontakter på hver søm, men resultatet var verdt det. Backenderen vår Pasha viste mirakler av dyktighet, og gjorde det på mindre enn noen få timer.
Første tester av iot-enheten og etterbehandling
Vi gjorde de første testene og samtidig kom nye oppgaver til oss. Faktum er at midt i prosessen ble en ekte filmprodusent og kameramann fra VGIK, Ilya Serov, med på laget - han bygde rammen, la til ekstra kinobelysning og endret litt på spillmanuset for å gjøre handlingen mer emosjonell, og bildet mer dramatisk og teatralsk.
Dette økte kvaliteten betydelig, men det dukket opp elementer som også måtte kobles til reléet og driftsalgoritmen foreskrevet.
Et annet problem var laseren: vi gjorde flere eksperimenter med forskjellige typer tau og lasere med forskjellig kraft. Til testen hengte vi rett og slett en vekt vertikalt på et tau.
Når du løp med en testtoken, var kraften regulert gjennom PWM mindre enn 10 % og skadet ikke tauet selv med lang eksponering.
For kampmodus ble laseren ufokusert til omtrent et sted med en diameter på 10 mm, og den brant trygt gjennom et tau med en belastning fra en avstand på omtrent en meter.
Så laseren fungerte perfekt i tester
Da vi begynte å teste alt rett i rommet på en hengende vekt, viste det seg at det ikke var så lett å sikre laseren sikkert. Så, når tauet brenner, smelter det, strekker seg og beveger seg ut av sitt opprinnelige fokus.
Men det fungerte ikke lenger slik: tauet forskjøv seg
Ilya flyttet laseren til enden av rommet motsatt tauet slik at laserstrålen skulle gå over hele scenen og se vakker ut i rammen, noe som doblet avstanden.
Etter å ha utført flere eksperimenter med å brenne tauet allerede i kamp, bestemte vi oss for ikke å torturere skjebnen og sikre kuttingen av tauet ved hjelp av nikromtråd. Den ødela tråden 120 sekunder etter å ha slått på laseren i kampmodus. Vi bestemte oss for å hardkode dette, samt frakobling av ledningen og tenning av røykbomber når separasjonskontakten utløses, direkte inn i maskinvaren til mikrokontrolleren.
Tråden som til slutt brant gjennom tauet utenfor skjermen
Dermed dukket det opp en tredje oppgave som Arduino løste - å regne ut sekvensene knyttet til utførelsen av disse kommandoene.
Vi bestemte oss også for å gi Arduinoen behovet for å telle penger på TV-en og kjøre makuleringsmaskinen. I utgangspunktet ble det antatt at backend ville gjøre dette og gjeldende balanse ville være synlig på nettsiden, og på TV-en ville vi vise kommentarer fra YouTube som et ekstra interaktivt element, og fortelle seerne at hendelsene i rommet skjedde i virkeligheten tid.
Men under testkjøringen så Ilya på scenen og foreslo å vise spillbalansen på den største skjermen: hvor mye penger som er igjen, hvor mye som er spist, og nedtellingen til neste start av makuleringsmaskinen.
Vi knyttet Arduino til gjeldende tid: hver hele time ble makuleringsmaskinen startet. Bildet ble vist på TV-en ved hjelp av rasberry, som i det øyeblikket allerede mottok forespørsler fra serveren og sendte dem til arduinoen for utførelse. Bilder med pengeindikatorer ble tegnet ved å kalle konsollverktøyet fim noe sånt som dette
image = subprocess.Popen(["fim", "-q", "-r", "1920×1080", fim_str]), где fim_str
Og den ble dannet basert på den nødvendige mengden eller tiden.
Vi genererte bildene på forhånd: vi tok ganske enkelt en ferdig video med en timer og eksporterte 200 bilder.
Dette er mekanikken som ble programmert inn i korset. Da den endelige nedtellingen startet, dro vi alle til stedet, bevæpnet oss med brannslukningsapparater og satte oss ned for å vente på brannen (som bare var i full gang i uenigheten)
Hvordan lage en sending som fungerer i en uke: velge et kamera
For oppdraget trengte vi en kontinuerlig sending på YouTube i 7 dager - det er akkurat det vi satte som maksimal varighet for spillet. Det var to ting som kunne stoppe oss:
- Overoppheting av kameraet på grunn av kontinuerlig drift
- Internett-brudd
Kameraet måtte gi minst et Full HD-bilde for å gjøre det behagelig å spille og se på rommet.
I utgangspunktet så vi mot webkameraer som er produsert for streamere. Vi kuttet budsjettet vårt, så vi ønsket ikke å kjøpe et kamera, men det viste seg at de ikke leier dem. I samme øyeblikk fant vi mirakuløst et Xbox Kinect-kamera liggende i huset mitt, installerte det på rommet mitt og startet en testsending i en uke.
Kameraet fungerte fint og ble ikke overopphetet, men Ilya la nesten umiddelbart merke til at det manglet innstillinger, spesielt var det umulig å stille inn eksponeringen.
Ilya forsøkte å bringe typen sending nærmere standardene for film- og videoproduksjon: å formidle en dynamisk skiftende lysscene med sterke lyskilder, en mørk bakgrunn og objekter i rammen. Samtidig ønsket jeg å bevare utarbeidingen av bildet både i høylys og skygger, med minimalt med digital støy.
Derfor, selv om Kinect viste seg å være pålitelig i tester og ikke krevde et videoopptakskort (et annet feilpunkt), bestemte vi oss for å forlate det. Etter tre dager med testing av forskjellige kameraer, valgte Ilya Sony FDR-AX53 - et lite, pålitelig videokamera som er rimelig å leie, men som samtidig har tilstrekkelig pålitelighet og visuelle egenskaper.
Vi leide et kamera, slo det på i en uke sammen med et videoopptakskort, og innså at med det kunne vi stole på kontinuerlig kringkasting gjennom hele oppdraget.
Lage en film: iscenesette scene og lyssetting
Å jobbe med belysningen krevde en viss nåde; vi trengte å bygge en lysscore med minimale midler:
1. Belysning av objekter når spillere finner dem (laser, vekt), samt konstant lys på makuleringsmaskinen. Her brukte vi dedolight 150 - pålitelige og kompakte filmbelysningsenheter med lavspente halogenlamper, som lar deg fokusere strålen på et bestemt objekt uten å påvirke bakgrunnen og andre objekter.
2. Praktisk lekelys - bordlampe, gulvlampe, stjerne, krans. Alt praktisk lys ble harmonisk fordelt i rammen for å lyse opp bildeområdet, det var LED-lamper med en fargetemperatur på 3200K inne, lampen i gulvlampen var dekket med et rødt Rosco-foliefilter for å skape en uvanlig fargeaksent.
Jeg er ingeniør hos mamma eller lanseringen er i morgen
Hvordan vi reserverte internett og strøm
De nærmet seg spørsmålet om feiltoleranse nesten som i et datasenter: de bestemte seg for ikke å avvike fra de grunnleggende prinsippene og reserverte i henhold til den vanlige N+1-ordningen.
Hvis sendingen på YouTube stopper, betyr dette at det vil være umulig å koble til igjen ved å bruke samme lenke og fortsette strømmen. Det var et kritisk øyeblikk, og rommet lå på et vanlig kontor.
Til dette brukte vi en OpenWRT-basert ruter og mwan3-pakken. Den testet automatisk tilgjengeligheten til kanalen hvert 5. sekund, og i tilfelle en pause byttet den til backup-modemet med Yota. Som et resultat skjedde bytte til sikkerhetskopikanalen på mindre enn ett minutt.
Det var også like viktig å eliminere strømbrudd, fordi selv en kortvarig strømstøt ville føre til en omstart av alle datamaskiner.
Derfor tok vi en ippon innova g2 3000 avbruddsfri strømforsyning, som ville sikkerhetskopiere alle spillenheter: det totale strømforbruket til systemet vårt var rundt 300 watt. Det ville vare i 75 minutter, ganske nok for våre formål.
Vi bestemte oss for å ofre ekstra belysning i tilfelle strømmen i rommet gikk ut - det var ikke koblet til en avbruddsfri strømforsyning.
Anerkjennelser
- Til hele laget , som oppfant og implementerte spillet.
- Separat, for RUVDS-administratorene, for å overvåke arbeidet til serverne, var belastningen akseptabel og alt fungerte som vanlig.
- Til den beste sjefen for det faktum at som svar på anropet: "Jeg har en idé: vi tar en server, legger et akvarium på den og henger en vekt over den, bom, bang, alt er oversvømmet med vann, kortslutning, brann !" han sier alltid selvsikkert "gjør det!"
- Takk og separat til Mikhail Karpov for ikke bare å møte halvveis og tillate oss å bryte vilkårene for bruk, men til og med gi oss en bedriftskonto i et år da vi snakket om prosjektet.
- Ilya Serov for å være med og bli medprodusent av prosjektet, klar til å krype halve natten, lime LED-stripe, lete etter tekniske løsninger og gjøre alt for at vi skal få en ekte film.
- for alltid å være klar til å redde situasjonen når andre kastet opp hendene, borsjtsj, moralsk støtte og samtaler til morgenen.
- for å ha knyttet oss til landets beste pentester, som ga råd og hjalp oss med oppgaver.
- for den kule videoproduksjonen av alle videoene.
- for en fast hånd og vilje til å jobbe til det siste.
- godt for nesten alltid varm pizza.
Og den største takknemligheten går til spillerne for alle følelsene vi opplevde mens dere stormet oppdraget i to dager uten søvn og til og med utsette arbeidet.
Andre artikler om søken etter å ødelegge serveren
Kilde: www.habr.com