Hai un par de semanas pasámolo : construíron unha sala, que encheron con dispositivos intelixentes e lanzaron desde ela unha emisión en YouTube. Os xogadores podían controlar os dispositivos IoT desde o sitio web do xogo; O obxectivo era atopar unha arma escondida na sala (un poderoso punteiro láser), pirateala e provocar un curtocircuíto na sala.
Para engadir á acción, colocamos unha trituradora na sala, na que cargamos 200 rublos: a trituradora comía un billete por hora. Despois de gañar o xogo, podes parar a trituradora e levar todo o diñeiro restante.
Xa o contamos E proxecto. Chegou o momento de falar sobre o hardware e como foi montado.
Houbo moitas solicitudes para mostrar o momento de limpar unha habitación: mostramos como a desmontamos
Arquitectura de hardware: Control de sala
Comezamos a deseñar unha solución de hardware cando xa se entendía aproximadamente o escenario, o backend estaba listo e tiñamos unha sala baleira lista para instalar o equipo.
Lembrando a vella broma "A S en IoT significa Seguridade" ("A letra S na abreviatura de IoT significa Seguridade"), decidimos que esta vez os xogadores do escenario do xogo interactúan só co front-end e back-end. do sitio, pero non tes a oportunidade de chegar directamente ao ferro.
Fíxose por razóns de seguridade e espectáculo do que estaba a suceder na pantalla: co acceso directo ao hardware dos xogadores, sería moito máis difícil illar accións seguras e potencialmente perigosas, por exemplo, o desprazamento rápido dunha trituradora ou o control. pirotecnia.
Antes de comezar o deseño, formulamos varios principios para controlar os dispositivos de xogo, que se converteron na base do deseño:
Non use solucións sen fíos
Todo o espazo de xogo está nun cadro, cada recuncho do cal se pode alcanzar. Non había necesidade real de conexións sen fíos e simplemente converteríanse noutro punto de falla.
Non use ningún dispositivo doméstico intelixente especial
Principalmente en aras da flexibilidade de personalización. Está claro que podemos personalizar moitas versións en caixa de sistemas domésticos intelixentes con administradores e controis listos para a nosa tarefa, pero os custos laborais serían comparables aos de crear a túa propia solución sinxela.
Ademais, foi necesario elaborar aparellos que demostrasen claramente que eran os xogadores os que cambiaban o seu estado: acenderon/apagaban ou poñían unha luz específica nas letras FALCON.
Recollemos todos os elementos do hardware dispoñible ao público que se pode mercar nas tendas de pezas de radio habituais: entre a entrega de pizza e cola dietética, os correos Chip and Dip e Leroy acudían constantemente ao sitio.
A elección de montar todo nós mesmos simplificou a depuración, a escalabilidade, con todo, requiriu un maior coidado durante a instalación.
Todos os relés e arudin non deben ser visibles no cadro
Decidimos reunir todos os elementos controlables nun só lugar e ocultalos entre bastidores para poder supervisar o seu rendemento e, se é necesario, arrastrar coidadosamente fóra do rango de visibilidade da cámara e substituír a unidade avariada.
Ao final, todo quedou oculto debaixo da mesa, e instalouse a cámara para que nada fose visible debaixo da mesa. Este foi o noso "punto cego" para que o enxeñeiro se arrastrase
Como resultado, en realidade obtivemos un dispositivo intelixente: recibiu o estado de cada unha das súas partes do backend e cambiouno co comando adecuado.
Desde o punto de vista da implementación do hardware, este dispositivo controlaba 6 elementos:
- Varias lámpadas de mesa, teñen un estado on/off e son controladas polos xogadores
- Letras na parede, poden cambiar a súa cor ás ordes dos xogadores
- Fans que xiran e abren o rotafolio cando o servidor está baixo carga
- Controlado por láser mediante PWM
- Trituradora que comeu cartos no horario previsto
- Unha máquina de fume que se apagaba antes de cada disparo láser
Probando unha máquina de fume cun láser
Máis tarde, engadiuse unha luz de escenario, que estaba detrás do cadro e controlábase exactamente como as lámpadas do punto 1. A luz do escenario funcionou en dous casos: iluminaba o láser cando se lle aplicaba enerxía e iluminaba o peso antes do láser foi lanzado en modo de combate.
Cal era este dispositivo intelixente?
Durante todo o camiño, Yura, o noso tipo de hardware, intentou non complicar as cousas e dar coa solución máis sinxela e minimalista posible.
Supoñíase que o VPS simplemente executaría un script que recibe json co estado dos dispositivos e o envía ao Arduino conectado a través de USB.
Conectado aos portos:
- 16 relés habituais (foron eles os que facían o ruído de clic que se escoitaba no vídeo. Escollemolos principalmente por este son)
- 4 relés de estado sólido para controlar canles PWM, como ventiladores,
- saída PWM separada para láser
- saída que xera un sinal á tira de LED
Aquí tes un exemplo dun comando json que chegou ao relé desde o servidor
{"power":false,"speed":0,"period":null,"deviceIdentifier":"FAN"}E este é un exemplo dunha función coa que o mando chegou a Arudino
def callback(ch, method, properties, body):
request = json.loads(body.decode("utf-8"))
print(request, end="n")
send_to_serial(body)Para rastrexar o momento no que o láser finalmente queima a corda e o peso voa cara ao acuario, fixemos un pequeno botón que se activaba cando o peso caía e deu un sinal ao sistema.
Botón para controlar o movemento do peso
A este sinal, debían acenderse bombas de fume feitas con pelotas de ping-pong. Puxemos 4 bengalas de fume directamente na caixa do servidor e conectámolas cun fío de nicromo, que debía quentar e funcionar como un acendedor.
Vivenda con bombas de fume e guirnalda chinesa
Arduino
Segundo o plan orixinal, realizáronse dúas actuacións no Arduino.
En primeiro lugar, cando se recibiu unha nova solicitude, a solicitude analizouse mediante a biblioteca ArduinoJson. A continuación, comparouse cada dispositivo xestionado coas súas dúas propiedades:
- estado de alimentación "on" ou "off" (estado estándar)
- o período durante o que se acende o dispositivo: o tempo en microsegundos desde o inicio do taboleiro, cando é hora de apagalo, é dicir, levar o estado ao estándar
A última vez que se definiu ao recibir o parámetro correspondente en JSON, pero non se puido transmitir, entón o valor estableceuse en 0 e non se produciu ningún reinicio.
A segunda acción que realizaba o Arduino cada ciclo era actualizar estados, é dicir, comprobar se había que acender algo ou se era hora de apagar algún dispositivo.
Punteiro láser - o mesmo Megatron 3000
Este é un módulo de marcado e corte con láser de enfoque manual LSMVR450-3000MF 3000mW 450nm normal.
Letras Falcon
Fixéronse moi sinxelos: simplemente copiamos as letras do logotipo, recortámolas de cartón e despois cubrimos con cinta LED. Neste caso, tiven que soldar os anacos de cinta, 4 contactos en cada costura, pero o resultado valeu a pena. O noso backender Pasha mostrou milagres de habilidade, facéndoo en menos dunhas horas.
Primeiras probas do dispositivo iot e remate
Fixemos as primeiras probas e ao mesmo tempo nos chegaron novas tarefas. O feito é que no medio do proceso, un produtor de cine e cámara real de VGIK, Ilya Serov, uniuse ao equipo: construíu o cadro, engadiu unha iluminación adicional de cine e cambiou lixeiramente o guión do xogo para facer a trama máis emotiva e o cadro máis dramático e teatral.
Isto aumentou significativamente a calidade, pero apareceron elementos que tamén debían conectarse ao relé e ao algoritmo de operación prescrito.
Outro problema foi o láser: fixemos varios experimentos con distintos tipos de cordas e láseres de diferentes potencias. Para a proba, simplemente colgamos un peso verticalmente nunha corda.
Cando se executaba cun token de proba, a potencia regulada a través do PWM era inferior ao 10% e non danaba a corda mesmo cunha longa exposición.
Para o modo de combate, o láser desfocouse ata aproximadamente un punto cun diámetro de 10 mm e queimou con confianza a través dunha corda cunha carga a unha distancia de aproximadamente un metro.
Así que o láser funcionou perfectamente nas probas
Cando comezamos a probar todo ben na sala cun peso suspendido, resultou que asegurar o láser de forma segura non era tan sinxelo. Despois, cando a corda arde, derrete, estirase e móvese fóra do seu foco orixinal.
Pero xa non funcionaba así: a corda cambiou
Ilya moveu o láser ao final da sala fronte á corda para que o raio láser atravesase todo o escenario e quedara fermoso no cadro, o que duplicou a distancia.
Despois de realizar varios experimentos máis coa queima da corda xa na batalla, decidimos non torturar o destino e asegurar o corte da corda con fío de nicromo. Destruíu o fío 120 segundos despois de acender o láser en modo de combate. Decidimos codificar isto, así como a desconexión do cable e a ignición das bombas de fume cando se activa o contacto de separación, directamente no hardware do microcontrolador.
O fío que finalmente queimou a corda fóra da pantalla
Así, apareceu unha terceira tarefa que Arduino resolveu: elaborar as secuencias asociadas á execución destes comandos.
Tamén decidimos darlle ao Arduino a necesidade de contar cartos na televisión e executar a trituradora. Inicialmente, supoñíase que o backend faría isto e que o saldo actual sería visible no sitio web, e na televisión mostrábamos comentarios de YouTube como un elemento interactivo adicional, dicindo aos espectadores que os eventos da sala estaban ocorrendo en realidade. tempo.
Pero durante a proba, Ilya mirou a escena e suxeriu mostrar o saldo do xogo na pantalla máis grande: canto diñeiro aínda queda, canto se comeu e a conta atrás para o seguinte inicio da trituradora.
Atamos Arduino á hora actual: cada hora enteira comezaba a trituradora. A imaxe mostrábase no televisor usando rasberry, que nese momento xa estaba recibindo solicitudes do servidor e enviándoas ao arduino para a súa execución. As imaxes con indicadores monetarios debuxáronse chamando á utilidade da consola fim algo así
image = subprocess.Popen(["fim", "-q", "-r", "1920×1080", fim_str]), где fim_str
E formouse en función da cantidade ou tempo necesario.
Xeramos as imaxes con antelación: simplemente fixemos un vídeo preparado cun temporizador e exportamos 200 imaxes.
Esta é a mecánica que foi programada na cruz. Cando comezou a conta atrás final, todos fomos ao lugar, armámonos de extintores e sentámonos a esperar o lume (que só estaba en pleno apoxeo na discordia)
Como facer unha emisión que funcione durante unha semana: elixir unha cámara
Para a misión, necesitábamos unha emisión continua en YouTube durante 7 días; iso é exactamente o que definimos como duración máxima do xogo. Había dúas cousas que podían deternos:
- Sobrequecemento da cámara debido ao funcionamento continuo
- corte de internet
A cámara tiña que proporcionar polo menos unha imaxe Full HD para que xogar e ver a sala fose cómodo.
Inicialmente, buscamos cámaras web que se producen para streamers. Estabamos recortando o orzamento, así que non queriamos mercar unha cámara, pero, polo que se viu, non a alugan. No mesmo momento, atopamos milagrosamente unha cámara Xbox Kinect deitada na miña casa, instalámola no meu cuarto e iniciamos unha emisión de proba durante unha semana.
A cámara funcionou ben e non se quentaba en exceso, pero Ilya notou case inmediatamente que carecía de configuracións, en particular, era imposible establecer a exposición.
Ilya buscou achegar o tipo de emisión aos estándares da produción de películas e vídeos: transmitir unha escena de luz que cambia dinámicamente con fontes de luz brillante, un fondo escuro e obxectos no cadro. Ao mesmo tempo, quixen preservar a elaboración da imaxe tanto en luces como en sombras, cun mínimo ruído dixital.
Polo tanto, aínda que o Kinect demostrou ser fiable nas probas e non requiría unha tarxeta de captura de vídeo (outro punto de falla), decidimos abandonalo. Despois de tres días de probar diferentes cámaras, Ilya escolleu a Sony FDR-AX53: unha videocámara pequena e fiable que é barata de alugar, pero que ao mesmo tempo ten suficiente fiabilidade e características visuais.
Alugamos unha cámara, acendemos durante unha semana xunto cunha tarxeta de captura de vídeo e decatámonos de que con ela podíamos contar cunha emisión continua durante toda a misión.
Facer unha película: posta en escena e iluminación
Traballar na iluminación requiría unha certa gracia; necesitabamos construír unha partitura de iluminación con medios mínimos:
1. Iluminación dos obxectos cando os xogadores os atopan (láser, peso), así como luz constante na trituradora. Aquí usamos dedolight 150: dispositivos de iluminación de película fiables e compactos con lámpadas halóxenas de baixa tensión, que permiten enfocar o feixe nun obxecto específico sen afectar o fondo e outros obxectos.
2. Luz de xogo práctica: lámpada de mesa, lámpada de pé, estrela, guirlanda. Toda a luz práctica distribuíuse harmoniosamente no cadro para iluminar a zona da imaxe, no interior había lámpadas LED cunha temperatura de cor de 3200K, a lámpada da lámpada de pé estaba cuberta cun filtro de folla vermella Rosco para crear un acento de cor inusual.
Son enxeñeiro na miña nai ou o lanzamento é mañá
Como reservamos internet e electricidade
Abordaron o tema da tolerancia a fallos case como nun centro de datos: decidiron non desviarse dos principios básicos e reserváronse segundo o esquema N+1 habitual.
Se a emisión en YouTube se detén, isto significa que será imposible volver conectar coa mesma ligazón e continuar coa emisión. Foi un momento crítico, e a sala estaba situada nunha oficina normal.
Para iso usamos un enrutador baseado en OpenWRT e o paquete mwan3. Proba automaticamente a dispoñibilidade da canle cada 5 segundos e, en caso de interrupción, cambiaba ao módem de reserva con Yota. Como resultado, o cambio á canle de copia de seguranza produciuse en menos dun minuto.
Tamén era igualmente importante eliminar os cortes de enerxía, porque incluso un aumento de enerxía a curto prazo provocaría un reinicio de todos os ordenadores.
Polo tanto, tomamos unha fonte de alimentación ininterrompida ippon innova g2 3000, que faría unha copia de seguridade de todos os dispositivos de xogos: o consumo total de enerxía do noso sistema era duns 300 vatios. Duraría 75 minutos, o suficiente para os nosos propósitos.
Decidimos sacrificar a iluminación adicional no caso de que se apagase a electricidade da sala: non estaba conectada a unha fonte de alimentación ininterrompida.
Agradecementos
- A todo o equipo , quen inventou e implementou o xogo.
- Por separado, para os administradores de RUVDS, para supervisar o traballo dos servidores, a carga foi aceptable e todo funcionou como de costume.
- Ao mellor xefe polo feito de que en resposta á chamada “teño unha idea: colleremos un servidor, poñémoslle un acuario e colgaremos un peso encima, bum, bang, todo está inundado de auga, curtocircuíto, lume. !" sempre di con confianza "faino!"
- Grazas e por separado a Mikhail Karpov por non só reunirnos a metade e permitirnos violar as Condicións de uso, senón mesmo por darnos unha conta comercial durante un ano cando falamos do proxecto.
- Ilya Serov por unirse e converterse en coprodutor do proxecto, listo para arrastrarse media noite, pegar tira de LED, buscar solucións técnicas e facer todo para conseguir unha película de verdade.
- por estar sempre preparado para salvar a situación cando outros botaban as mans, borscht, apoio moral e conversacións ata a mañá.
- por conectarnos co mellor pentester do país, que nos asesorou e nos axudou nas tarefas.
- para a produción de vídeo xenial de todos os vídeos.
- por unha man firme e vontade de traballar ata o final.
- Ben para case sempre pizza quente.
E o agradecemento máis grande para os xogadores por todas as emocións que vivimos mentres asaltaches a busca durante dous días sen durmir e mesmo pospoñer o traballo.
Outros artigos sobre a procura de destruír o servidor
Fonte: www.habr.com