Iobroker busca por missões em jogos de realidade

Olá pessoal, já existem vários artigos sobre Habré sobre automação de jogos como "missões na realidade" ( uma , duas , três , quatro , cinco ...), também gostaria de compartilhar minha experiência de participar de um projeto desse tipo. Em 2015, meus amigos decidiram organizar uma missão na sala de fuga "Assalto a banco" em nossa cidade. Eles sabiam que eu gostava de várias automações por um longo tempo, incluindo sistemas como "casa inteligente" baseada em soluções de código aberto, então pediram ajuda na organização do jogo. Essa ideia me pareceu interessante e eu concordei - queria aplicar minha experiência e soluções para algo mais interessante do que piscar uma lâmpada no meu apartamento.

Tentei participar de todo o ciclo do projeto - desde fazer alterações no script até as próximas tarefas de execução, identificar e corrigir bugs, melhorias subseqüentes. Eu visitei vários jogos em nossa cidade (em 2015, eles podiam ser contados com os dedos de uma mão), não para os fãs, mas para ganhar experiência e soluções de engenharia reversa, e isso foi claramente visível pela reação dos organizadores. Mas depois de participar do jogo em Moscou, entendi a escala real do “desastre” e realmente queria fazer meu trabalho não pior do que o lado técnico. Então, a missão “Rob the Bank” em Tver, para detalhes de como foi criada e desenvolvida ao longo de vários anos, peço gato.

Descrição das soluções técnicas

Depois que meus colegas me explicaram nos dedos o que eles querem de mim e como tudo deve funcionar, na minha cabeça, literalmente, em alguns minutos, uma arquitetura tomou forma: um servidor central com a plataforma ioBroker , controladores locais baseados em placas e módulos Arduino, troca de dados com servidor e entre controladores usando o protocolo MQTT. Como resultado, a arquitetura acabou sendo aproximadamente da seguinte maneira:


Além da interação do controlador de tarefas com o servidor central, era necessário estabelecer a interação entre os controladores de diferentes tarefas de busca. Para isso, na minha opinião, o protocolo MQTT com um broker em um servidor central era ideal. Clientes - os controladores publicam seus estados no servidor, assinam os comandos do servidor e os estados de outros controladores. Para implementar essa solução, o adaptador MQTT foi usado - ele também era um broker MQTT e permitiu criar uma hierarquia de tópicos na árvore de objetos do ioBroker para usar os dados para visualização e gerenciamento (uma captura de tela abaixo da versão antiga do “painel de administração”).


Posteriormente, não me arrependi de ter escolhido exatamente essa solução:

1. O MQTT é um protocolo leve, a biblioteca ocupou pouco espaço e foi mais do que suficiente, mesmo para o Arduino UNO com o chip ATmega328
2. Ao reiniciar ou ligar os controladores pela primeira vez, eles receberam as condições iniciais para iniciar o trabalho usando o MQTT - é muito conveniente
3. Essa solução acabou sendo a mais confiável dentre as testadas e bastante simples para um iniciante implementar e estudar

Apenas algumas opções são obtidas pelos fluxos de dados, a mais simples delas - um evento ocorre no controlador de tarefa nº 1 (um botão é pressionado), publica o estado do botão em um determinado tópico e seu estado é exibido alterando a cor de um elemento gráfico na forma visual do operador.


Uma opção igualmente simples e oposta é que você precisa ativar manualmente o relé através do controlador de tarefa nº 1, um evento de controle é fornecido através do adaptador VIS, que altera o estado do tópico deste controlador e com ask = false. O adaptador MQTT recebe uma alteração de tópico com ask = false, portanto, este tópico não chegou do controlador, respectivamente, a alteração é publicada no controlador, que por sua vez publica uma confirmação com ask = true em resposta.


A troca entre controladores ocorre em um evento em um dos controladores. Por exemplo, o primeiro controlador cumpriu sua tarefa e deve ativar o relé no segundo controlador - publica seu status no tópico geral, o broker o exibe na árvore e na página de visualização, uma vez que o segundo controlador está inscrito neste tópico, o broker o publica no segundo controlador e o último, por sua vez, publica uma resposta de confirmação.


O projeto ainda tinha que adicionar a tarefa de interagir com um computador. A interface foi escrita em php, a página estava girando em um servidor WEB com execução automática no modo de navegador de tela cheia. A integração com o sistema principal foi realizada usando o driver simple-api - algumas solicitações php para o ioBroker simplesmente se contorceram através do php. A própria unidade do sistema estava escondida nas entranhas da mesa do escritório, a interface era controlada com o mouse e o expedidor de missões possuía um teclado sem fio.

A visualização para o operador foi desenvolvida no driver VIS para uma resolução - o monitor do operador, mas subseqüentemente a equipe da missão conseguiu usar tablets móveis com a mesma interface, e mostrou-se conveniente para redefinir a preparação para um novo jogo e diagnosticar o sistema. A interface acabou sendo espartana, sem painéis modernos e interruptores ryushek, mas compreensível, simples e rápido. Não havia necessidade de lógica, camadas, gráficos e outras coisas especiais na interface, apenas ícones para exibir o status do equipamento, botões para controle e vários campos de texto para exibir o modo de operação dos controladores e o log de operações do sistema.


No momento do desenvolvimento do projeto, não havia outras opções para o design de visualização. Posteriormente, os adaptadores de visualização apareceram para dispositivos móveis (eu uso material ) e para tablets / computadores estacionários: habpanel , lovelace , tileboard e outros.
A lógica principal foi estabelecida no código dos controladores, mas a interação geral, a inicialização dos parâmetros de inicialização, as funções de serviço etc. foram implementadas no servidor principal usando o adaptador javascript . O código foi escrito em JS usando as funções internas do ioBroker, seguidas de uma "mudança" para blockly (essa funcionalidade apareceu mais tarde que o início do trabalho no projeto).


No total, vários scripts estavam envolvidos:

1. Script para Inicialização Inicial do Sistema (Primeira Inclusão)
2. script para redefinir todos os controladores antes do próximo jogo
3. um dos controladores não "moveu-se" imediatamente para o MQTT; portanto, por algum tempo, um script foi usado para trocar com o controlador por meio de solicitações HTTP-GET
4. script para manter um log separado da jogabilidade

Todos os controladores baseados em placas Arduino UNO (posteriormente, vários controladores tiveram que ser convertidos em placas Arduino MEGA - não havia memória suficiente) foram equipados com uma placa de expansão Ethernet baseada no chip W5100. Troca de dados entre controladores e o servidor (conforme escrito acima) usando o protocolo MQTT. O desenvolvimento de algoritmos no IDE do Arduino foi realizado usando bibliotecas padrão. No lado do ferro, não há nada sobrenatural - o uso máximo de módulos prontos e placas de expansão com um mínimo de solda e sem a fabricação de placas personalizadas - tudo em placas de tábua de pão. Gerenciamento de carga através de módulos com relés convencionais e de estado sólido, comutadores de transistor para indicadores LED e cargas de baixa potência. Na parte mecânica, tentei usar o mínimo possível de elementos móveis: microinterruptores, empurradores, travas E / M e usar módulos de fotodiodo LED prontos (optoacopladores abertos), relés de estado sólido, travas magnéticas convencionais, leitores de cartões de proximidade e sensores de palheta. Algumas fotos abaixo:





Os controladores no local eram alimentados por adaptadores POE caseiros - os cabos de par trançado usavam núcleos ociosos para transmitir 12V DC. Conversão em placas controladoras através de placas DC-DC prontas até 5V - a partir da qual as próprias placas Arduino + Ethernet e carga de baixa potência com lógica de 5V foram alimentadas: LEDs de baixa corrente, relés, etc. - Linhas de cabo separadas foram usadas com parafuso de esfera ou fio PVA. Duas entradas de 220V CA foram trazidas para o gabinete principal de automação e um no-break foi conectado via contatores nos contatores, que por sua vez foram conectados via bypass, para facilitar a manutenção. Para alimentar toda a automação e baixa tensão, fontes de alimentação poderosas de 2 volts foram instaladas no gabinete, 2 por 12V e uma por 5V. No gabinete de automação, eles lançaram linhas de cabo 220V para alimentar computadores e vários periféricos da missão: de sopro a serra (viu)



As soluções restantes são bastante padrão para esses projetos. Sistema de videovigilância em câmeras IP com fio, sempre com iluminação IR e microfones embutidos. O fluxo de vídeo é usado em uma das tarefas da missão e é processado adicionalmente no PC do gerenciador de missões; o software de código aberto (ZoneMinder) é usado. A rede local de controladores Arduino foi separada do restante das redes, para que o fluxo das câmeras não carregasse os já fracos chips W5100 de placas ethernet.

Viva-voz com os participantes do jogo usando um amplificador soviético convencional e alto-falantes embutidos no teto.

No final, eu queria descrever um pequeno servidor central. A plataforma ioBroker é implantada na placa única BananaPi ARM, cuja potência acabou sendo suficiente para todas as tarefas. O ambiente é o sistema operacional Armbian, alguns scripts bash para trabalhar com GPIO e criar backups para a nuvem no Yandex.Disk. Vários GPIOs são usados ​​para indicar o status operacional de módulos e adaptadores (LEDs) individuais e um botão para desligar o sistema corretamente. Na foto do gabinete de 19 ”acima, pode-se ver que a placa está em um gabinete de plexiglass barato e mais tarde foi instalado em um gabinete de 1U com uma fonte de alimentação normal e outros periféricos.

Erros, armadilhas, dificuldades

Meus colegas e eu pensamos na arquitetura básica com bastante antecedência (eu fiz o projeto) e muitos nós foram montados e testados “na mesa”, para que não houvesse mudanças fundamentais. Pequenas "rugosidade" foram corrigidas no local. Os principais problemas, cuja solução levou bastante tempo:

1. Falta de memória do Arduino no chip 328, passando para a placa MEGA do Arduino. Previsivelmente, repousava em alguns controladores na memória do chip. Passava a maior parte do tempo retrabalhando os cartões de expansão.
2. Falhas no trabalho com o driver MQTT foram resolvidas rapidamente pelo autor do projeto ioBroker.
3. O processo longo e difícil de selecionar um navegador para a visualização normal no driver VIS. Acabou sendo difícil trabalhar com este adaptador. Como resultado, a edição foi realizada no navegador Chrome e o operador de tempo de execução lançou uma versão específica através do navegador Dragon. Como os bugs foram corrigidos, eles foram completamente movidos para o navegador Chrome mais recente.
4. Criação gradual de soluções anti-vandalismo - microinterruptores abandonados, botões e botões mecânicos, teclados de filmes, etc.
5. As fechaduras eletromecânicas do xerife eram de qualidade muito baixa; elas tiveram que ser substituídas localmente por fechaduras eletromagnéticas comuns.
6. A operação instável dos controladores Arduino ao trabalhar com câmeras IP, como resultado, as redes foram divididas e tudo funcionou como deveria.

Conclusão

Todo o projeto, desde estudar e concordar com o cenário até o lançamento dos primeiros grupos de teste, levou cerca de seis meses - muito, mas foi a primeira experiência e, além disso, eu quase acompanhei o trabalho principal de construção / reparo das instalações. Além disso, havia muito trabalho "em cima da mesa" - principalmente ao usar módulos separados do Arduino, porque eles não funcionavam exatamente como eu esperava. Ao implementar o projeto, tentamos, tanto quanto possível, aderir aos seguintes princípios:

1. O projeto envolvia manutenção e pequenos reparos por qualquer engenheiro que pelo menos uma vez tivesse um ferro de soldar nas mãos, sabia o que era o Arduino e seria capaz de "piscar" o LED soldado na placa.
2. Desenvolvimento no Arduino IDE usando bibliotecas padrão para máxima simplicidade.
3. Maximize o uso de módulos comuns prontos para uso em um projeto para facilitar a manutenção e a substituição
4. Use protocolos padrão e redes de dados
5. Minimize o número de peças mecânicas para maior durabilidade e anti-vandalismo.

Como resultado, nas primeiras duas semanas, acabou por se livrar de todas as pequenas falhas e agora o sistema trabalha há quase 4 anos no quase ambiente inicial.