Iobroker búsqueda de misiones en juegos de realidad

Hola a todos, ya hay varios artículos sobre Habré sobre la automatización de juegos como "misiones en la realidad" ( uno , dos , tres , cuatro , cinco ...), también me gustaría compartir mi experiencia de participar en un proyecto de este tipo. En 2015, mis amigos decidieron organizar una búsqueda en la sala de escape "Robo a un banco" en nuestra ciudad. Sabían que me había gustado la automatización durante mucho tiempo, incluidos los sistemas como "hogar inteligente" basados ​​en soluciones de código abierto, por lo que pidieron ayuda para organizar el juego. Esta idea me pareció interesante y acepté: quería aplicar mi experiencia y soluciones para algo más interesante que parpadear una bombilla en mi departamento.

Intenté participar en el ciclo completo del proyecto, desde hacer cambios en el script hasta las siguientes tareas de ejecución, identificar y corregir errores, mejoras posteriores. Visité varios juegos en nuestra ciudad (en 2015 se podían contar con los dedos de una mano), no para el fanático, sino para ganar experiencia y soluciones de ingeniería inversa, y esto fue claramente visible por la reacción de los organizadores. Pero después de participar en el juego en Moscú, entendí la escala real del "desastre" y realmente quería hacer mi trabajo no peor que el aspecto técnico. Entonces, la búsqueda "Rob the Bank" en Tver, para obtener detalles sobre cómo se creó y desarrolló a lo largo de varios años, le pido un gato.

Descripción de soluciones técnicas.

Después de que mis colegas me explicaron con los dedos lo que querían de mí y cómo debería funcionar todo, literalmente en un par de minutos se formó una arquitectura: un servidor central con plataforma ioBroker , controladores locales basados ​​en placas y módulos Arduino, intercambio de datos con servidor y entre controladores que utilizan el protocolo MQTT. Como resultado, la arquitectura resultó ser aproximadamente la siguiente:


Además de la interacción del controlador de tareas con el servidor central, fue necesario establecer la interacción entre los controladores de diferentes tareas de búsqueda. Para esto, en mi opinión, el protocolo MQTT con un corredor en un servidor central era ideal. Clientes: los controladores publican sus estados en el servidor, se suscriben a los comandos del servidor y los estados de otros controladores. Para implementar esta solución, se utilizó el adaptador MQTT ; también era un agente MQTT y le permitía crear una jerarquía de temas en el árbol de objetos ioBroker para usar los datos para visualización y administración (una captura de pantalla debajo de la versión anterior del "panel de administración").


Posteriormente, no me arrepentí de haber elegido una solución así:

1. MQTT es un protocolo ligero, la biblioteca ocupaba poco espacio y era más que suficiente incluso para el Arduino UNO con el chip ATmega328
2. Al reiniciar o encender los controladores por primera vez, recibieron las condiciones iniciales para comenzar a trabajar con MQTT; es muy conveniente
3. Esta solución resultó ser la más confiable de las probadas y bastante simple para que un principiante la implemente y estudie

Los flujos de datos solo obtienen algunas opciones, la más simple de ellas: se produce un evento en el controlador de tareas n. ° 1 (se presiona un botón), publica el estado del botón en un tema determinado y su estado se muestra al cambiar el color de un elemento gráfico en la forma visual del operador.


No menos simple y la opción opuesta: debe encender manualmente el relé a través del controlador de tareas n. ° 1, se suministra un evento de control a través del adaptador VIS, que cambia el estado del tema de este controlador, y con ask = false. El adaptador MQTT recibe un cambio de tema con ask = false, por lo que este tema no llegó del controlador, respectivamente, el cambio se publica en el controlador, que a su vez publica una confirmación con ask = true en respuesta.


El intercambio entre controladores se produce en un evento en uno de los controladores. Por ejemplo, el primer controlador ha cumplido su tarea y debe encender el relé en el segundo controlador: publica su estado en el tema general, el intermediario lo muestra en el árbol y en la página de visualización, ya que el segundo controlador está suscrito a este tema, el intermediario lo publica en el segundo controlador y este último a su vez publica una respuesta de confirmación.


El proyecto aún tenía que agregar la tarea de interactuar con una computadora. La interfaz estaba escrita en php, la página giraba en un servidor WEB con ejecución automática en modo de navegador de pantalla completa. La integración con el sistema principal se llevó a cabo utilizando el controlador simple-api : ciertas solicitudes de php a ioBroker simplemente se movieron a través de php. La unidad del sistema estaba oculta en las entrañas del escritorio de la oficina, la interfaz se controlaba con el mouse y el despachador de misiones tenía un teclado inalámbrico.

La visualización para el operador se desarrolló en el controlador VIS para una resolución: el monitor del operador, pero posteriormente el personal de búsqueda pudo usar tabletas móviles con la misma interfaz, resultó ser conveniente para reiniciar en preparación para un nuevo juego y para diagnosticar el sistema. La interfaz resultó ser espartana, sin tableros de moda y conmutadores ryushek, pero comprensible, simple y rápida. No había necesidad de lógica especial, capas, gráficos o cualquier otra cosa en la interfaz, solo íconos para mostrar el estado del equipo, botones para el control y varios campos de texto para mostrar el modo de operación de los controladores y el registro de operación del sistema.


En el momento del desarrollo del proyecto, no había otras opciones de visualización. Más tarde, aparecieron adaptadores de visualización tanto para dispositivos móviles (uso material ) como para tabletas / computadoras estacionarias: habpanel , lovelace , tileboard y otros.
La lógica principal se estableció en el código de los controladores, pero la interacción general, la inicialización de los parámetros para el inicio, las funciones de servicio, etc., se implementaron en el servidor principal utilizando el adaptador de JavaScript . El código se escribió en JS utilizando las funciones integradas de ioBroker, seguido de un "movimiento" de forma bloqueada (esta funcionalidad apareció más tarde que el inicio del trabajo en el proyecto).


En total, estuvieron involucrados varios guiones:

1. secuencia de comandos para la inicialización del sistema inicial (primera inclusión)
2. script para restablecer todos los controladores antes del próximo juego
3. uno de los controladores no se "movió" de inmediato a MQTT, por lo que durante algún tiempo se usó un script para intercambiar con el controlador a través de solicitudes HTTP - GET
4. guión para mantener un registro separado de la jugabilidad

Todos los controladores basados ​​en placas Arduino UNO (más tarde, varios controladores tuvieron que convertirse en placas Arduino MEGA, no había suficiente memoria) estaban equipados con una tarjeta de expansión Ethernet basada en el chip W5100. Intercambio de datos entre controladores y el servidor (como se escribió anteriormente) utilizando el protocolo MQTT. El desarrollo de algoritmos en Arduino IDE se llevó a cabo utilizando bibliotecas estándar. En el lado del hierro, no hay nada sobrenatural: el uso máximo de módulos listos para usar y tarjetas de expansión con un mínimo de soldadura y sin la fabricación de tableros personalizados, todo en tableros de tablero. Gestión de carga a través de módulos con relés de estado sólido y convencionales, interruptores de transistor para indicadores LED y cargas de baja potencia. En la parte mecánica, traté de usar elementos móviles lo menos posible: microinterruptores, pulsadores, bloqueos E / M y usar módulos LED de fotodiodo (optoacopladores abiertos), relés de estado sólido, bloqueos magnéticos convencionales, lectores de tarjetas de proximidad y sensores de láminas. Algunas fotos a continuación:





Los controladores en el sitio se alimentaron a través de adaptadores POE caseros: los cables de par trenzado usaban núcleos inactivos para transmitir 12 V CC. Conversión en placas controladoras a través de placas DC-DC preparadas de hasta 5V, desde las cuales se alimentaron las placas Arduino + Ethernet y una carga de baja potencia con lógica de 5V: LED de baja corriente, relés, etc. - Se utilizaron líneas de cable separadas con un tornillo de bola o alambre de PVA. Se introdujeron dos entradas de CA de 220 V en el gabinete de automatización principal y se conectó un UPS a través de contactores en los contactores, que a su vez se conectaron a través de derivación, para facilitar el mantenimiento. Para alimentar toda la automatización y bajo voltaje, se instalaron potentes fuentes de alimentación de 2 voltios en el gabinete, 2 por 12 V y uno por 5 V. Desde el gabinete de automatización, lanzaron líneas de cable de 220V para alimentar computadoras y varios periféricos de la búsqueda: de puff-puff a viu-viu))



Las soluciones restantes son bastante estándar para tales proyectos. Sistema de video vigilancia en cámaras IP con cable, siempre con iluminación IR y micrófonos incorporados. La transmisión de video se usa en una de las tareas de búsqueda y se procesa adicionalmente en la PC del administrador de misiones; se usa el software de código abierto (ZoneMinder). La red local de controladores Arduino se separó del resto de las redes para que la transmisión de las cámaras no cargara los chips W5100 de placas de ethernet ya débiles.

Manos libres con los participantes en el juego usando un amplificador soviético convencional y altavoces de techo incorporados.

Al final, quería describir un pequeño servidor central. La plataforma ioBroker se implementa en la placa única BananaPi ARM, cuyo poder resultó ser suficiente para todas las tareas. El entorno es el sistema operativo Armbian, un par de scripts de bash para trabajar con GPIO y para crear copias de seguridad en la nube en Yandex.Disk. Se utilizan varios GPIO para indicar el estado operativo de módulos y adaptadores (LED) individuales y un botón para apagar el sistema correctamente. En la foto del gabinete de 19 "arriba se puede ver que la placa está en una caja de plexiglás barata estándar; luego se instaló en una caja de 1U con una fuente de alimentación normal y otros periféricos.

Errores, dificultades, dificultades

Mis colegas y yo pensamos en la arquitectura básica con bastante antelación (hice el proyecto) y muchos nodos se ensamblaron y probaron "sobre la mesa", por lo que no hubo cambios fundamentales. Pequeñas "asperezas" fueron reparadas en el acto. Los principales problemas, cuya solución tomó bastante tiempo:

1. Falta de memoria Arduino en el chip 328, moviéndose a la placa Arduino MEGA. Previsiblemente descansaba en algunos controladores en la memoria del chip. La mayor parte del tiempo se dedicó a reelaborar las tarjetas de expansión.
2. Las fallas en el trabajo con el controlador MQTT fueron resueltas rápidamente por el autor del proyecto ioBroker.
3. El largo y difícil proceso de seleccionar un navegador para la visualización normal en el controlador VIS. Resultó ser difícil trabajar con este adaptador. Como resultado, la edición se realizó en el navegador Chrome, y el operador de tiempo de ejecución lanzó una versión específica a través del navegador Dragon. A medida que se corrigieron los errores, se trasladaron completamente al último navegador Chrome.
4. Creación gradual de soluciones antivandálicas: microinterruptores abandonados, botones mecánicos y pulsadores, teclados de película, etc.
5. Las cerraduras electromecánicas del Sheriff resultaron ser de muy baja calidad; tuvieron que ser reemplazadas localmente por cerraduras electromagnéticas comunes.
6. El funcionamiento inestable de los controladores Arduino cuando se trabaja con cámaras IP, como resultado, las redes se dividieron y todo funcionó como debería.

Conclusión

Todo el proyecto, desde estudiar y acordar el escenario hasta el lanzamiento de los primeros grupos de prueba, tomó aproximadamente seis meses, mucho, pero fue la primera experiencia y, además, casi seguí con el trabajo principal en la construcción / reparación de las instalaciones. Además, había mucho trabajo "sobre la mesa", principalmente cuando se usaban módulos Arduino separados, porque no funcionaban exactamente como esperaba. Al implementar el proyecto, tratamos lo más posible de cumplir con los siguientes principios:

1. El proyecto incluía mantenimiento y reparaciones menores por parte de cualquier ingeniero que al menos una vez sostuvo un soldador en sus manos, sabía lo que era el Arduino y podría "parpadear" el LED soldado en el tablero.
2. Desarrollo en Arduino IDE utilizando bibliotecas estándar para la máxima simplicidad.
3. Maximice el uso de módulos comunes disponibles en un proyecto para facilitar el mantenimiento y el reemplazo
4. Utilice protocolos estándar y redes de datos.
5. Minimice la cantidad de piezas mecánicas para mayor durabilidad y antivandalismo.

Como resultado, en las primeras dos semanas resultó deshacerse de todos los defectos menores y ahora el sistema ha estado funcionando durante casi 4 años en casi el entorno inicial.