Iobroker quest for quests in reality games

Bonjour à tous, il y a déjà plusieurs articles sur Habré sur l'automatisation de jeux comme les "quêtes en réalité" ( un , deux , trois , quatre , cinq ...), je voudrais également partager mon expérience de participation à un tel projet. En 2015, mes amis ont décidé d'organiser une quête d'évasion «Bank Robbery» dans notre ville. Ils savaient que j'aimais depuis longtemps diverses automatisations, y compris des systèmes tels que la «maison intelligente» basée sur des solutions open source, alors ils ont demandé de l'aide pour organiser le jeu. Cette idée m'a semblé intéressante et j'ai accepté - je voulais appliquer mon expérience et mes solutions à quelque chose de plus intéressant que de faire clignoter une ampoule dans mon appartement.

J'ai essayé de participer au cycle complet du projet - de la modification du script aux tâches de run-in suivantes, l'identification et la correction des bogues, les améliorations ultérieures. J'ai visité plusieurs jeux dans notre ville (en 2015, on pouvait les compter sur les doigts d'une main), pas pour les fans, mais plutôt pour acquérir de l'expérience et des solutions de rétro-ingénierie, et cela a été clairement visible par la réaction des organisateurs. Mais après avoir participé au match à Moscou, j'ai compris l'ampleur réelle de la «catastrophe» et je voulais vraiment faire mon travail pas pire que le côté technique. Donc, la quête «Rob the Bank» à Tver, pour plus de détails sur la façon dont il a été créé et développé au cours de plusieurs années, je demande chat.

Description des solutions techniques

Après que mes collègues m'ont expliqué du bout des doigts ce qu'ils attendaient de moi et comment tout devrait fonctionner, dans ma tête littéralement en quelques minutes une architecture a pris forme: un serveur central avec la plate- forme ioBroker , des contrôleurs locaux basés sur des cartes et modules Arduino, l'échange de données avec serveur et entre les contrôleurs utilisant le protocole MQTT. En conséquence, l'architecture s'est avérée être approximativement la suivante:


En plus de l'interaction du contrôleur de tâche avec le serveur central, il était nécessaire d'établir une interaction entre les contrôleurs des différentes tâches de quête. Pour cela, à mon avis, le protocole MQTT avec un courtier sur un serveur central était parfaitement adapté. Clients - les contrôleurs publient leurs états sur le serveur, s'abonnent aux commandes du serveur et aux états des autres contrôleurs. Pour implémenter cette solution, l'adaptateur MQTT a été utilisé - c'était également un courtier MQTT et vous a permis de créer une hiérarchie de sujets dans l'arborescence d'objets ioBroker pour utiliser les données pour la visualisation et la gestion (une capture d'écran sous l'ancienne version du «panneau d'administration»).


Par la suite, je n'ai pas regretté d'avoir choisi une telle solution:

1. MQTT est un protocole léger, la bibliothèque a pris peu de place et était largement suffisante même pour l'Arduino UNO avec la puce ATmega328
2. Lors du redémarrage ou de la mise sous tension des contrôleurs pour la première fois, ils ont reçu les conditions initiales pour commencer à travailler avec MQTT - c'est très pratique
3. Cette solution s'est avérée être la plus fiable de celles testées et assez simple pour un débutant à mettre en œuvre et à étudier

Seules quelques options sont obtenues par les flux de données, les plus simples d'entre elles - un événement se produit dans le contrôleur de tâches n ° 1 (un bouton est enfoncé), il publie l'état du bouton dans une certaine rubrique et son état est affiché en changeant la couleur d'un élément graphique sur la forme visuelle de l'opérateur.


Une option tout aussi simple et opposée est que vous devez activer manuellement le relais via le contrôleur de tâche n ° 1, un événement de contrôle est fourni via l'adaptateur VIS, qui change l'état du sujet de ce contrôleur, et avec ask = false. L'adaptateur MQTT reçoit un changement de rubrique avec ask = false, de sorte que cette rubrique n'est pas arrivée du contrôleur, respectivement, la modification est publiée sur le contrôleur, qui à son tour publie une confirmation avec ask = true en réponse.


L'échange entre contrôleurs se produit lors d'un événement sur l'un des contrôleurs. Par exemple, le premier contrôleur a rempli sa tâche et doit activer le relais sur le deuxième contrôleur - il publie son état dans la rubrique générale, le courtier l'affiche dans l'arborescence et sur la page de visualisation, puisque le deuxième contrôleur est abonné à cette rubrique, le courtier le publie sur le deuxième contrôleur et ce dernier publie à son tour une réponse de confirmation.


Le projet devait encore ajouter la tâche d'interagir avec un ordinateur. L'interface a été écrite en php, la page tournait sur un serveur WEB avec autorun en mode navigateur plein écran. L'intégration avec le système principal a été réalisée à l'aide du pilote simple-api - certaines requêtes php à ioBroker ont simplement été secouées via php. L'unité centrale elle-même était cachée dans les entrailles du bureau, l'interface était contrôlée avec la souris et le répartiteur de quêtes avait un clavier sans fil.

La visualisation pour l'opérateur a été développée dans le pilote VIS pour une résolution - le moniteur de l'opérateur, mais par la suite, le personnel de la quête a pu utiliser des tablettes mobiles avec la même interface, il s'est avéré pratique de réinitialiser en prévision d'un nouveau jeu et de diagnostiquer le système. L'interface s'est avérée être spartiate, sans tableaux de bord à la mode et commutateurs ryushek, mais compréhensible, simple et rapide. Il n'y avait pas besoin de logique spéciale, de couches, de graphiques ou de quoi que ce soit d'autre dans l'interface, seulement des icônes pour afficher l'état de l'équipement, des boutons de contrôle et plusieurs champs de texte pour afficher le mode de fonctionnement des contrôleurs et le journal des opérations du système.


Au moment du développement du projet, il n'y avait aucune autre option pour la conception de la visualisation. Plus tard, des adaptateurs de visualisation sont apparus à la fois pour les appareils mobiles (j'utilise du matériel ) et pour les tablettes / ordinateurs fixes : habpanel , lovelace , tileboard et autres.
La logique principale était définie dans le code des contrôleurs, mais l'interaction générale, l'initialisation des paramètres de démarrage, les fonctions de service, etc., ont été implémentées sur le serveur principal à l'aide de l'adaptateur javascript . Le code a été écrit en JS en utilisant les fonctions intégrées ioBroker, suivi d'un "move" vers blockly (cette fonctionnalité est apparue plus tard que le début du travail sur le projet).


Au total, plusieurs scripts ont été impliqués:

1. script pour l'initialisation initiale du système (première inclusion)
2. script pour réinitialiser tous les contrôleurs avant le prochain match
3. l'un des contrôleurs ne s'est pas immédiatement "déplacé" vers MQTT, donc pendant un certain temps un script a été utilisé pour échanger avec le contrôleur via HTTP - GET request
4. script pour maintenir un journal séparé du gameplay

Tous les contrôleurs basés sur des cartes Arduino UNO (plus tard, plusieurs contrôleurs ont dû être convertis en cartes Arduino MEGA - il n'y avait pas assez de mémoire) étaient équipés d'une carte d'extension Ethernet basée sur la puce W5100. Échange de données entre les contrôleurs et le serveur (comme écrit ci-dessus) en utilisant le protocole MQTT. Le développement d'algorithmes dans l'IDE Arduino a été réalisé à l'aide de bibliothèques standard. Du côté du fer, il n'y a rien de surnaturel - l'utilisation maximale de modules prêts à l'emploi et de cartes d'extension avec un minimum de soudure et sans la fabrication de cartes personnalisées - le tout sur des planches à pain. Gestion de la charge via des modules avec relais conventionnels et à semi-conducteurs, commutateurs à transistors pour indicateurs LED et charges de faible puissance. Sur la partie mécanique, j'ai essayé d'utiliser le moins possible d'éléments mobiles: micro-interrupteurs, poussoirs, verrous E / M et d'utiliser des modules de photodiode LED prêts à l'emploi (optocoupleurs ouverts), des relais statiques, des verrous magnétiques conventionnels, des lecteurs de cartes de proximité et des capteurs Reed. Quelques photos ci-dessous:





Les contrôleurs sur site étaient alimentés par des adaptateurs POE faits maison - les câbles à paire torsadée utilisaient des noyaux inactifs pour diffuser 12V DC. Conversion sur des cartes contrôleur via des cartes DC-DC prêtes à l'emploi jusqu'à 5 V - à partir desquelles les cartes Arduino + Ethernet elles-mêmes et une charge de faible puissance avec une logique 5 V ont été alimentées: LED à faible courant, relais, etc. Charge 12V plus puissante: verrous magnétiques, relais ou contacteurs puissants, divers équipements d'éclairage - Des câbles séparés ont été utilisés avec une vis à billes ou un fil PVA. Deux entrées 220 V CA ont été introduites dans l'armoire d'automatisation principale et un onduleur a été connecté via des contacteurs sur les contacteurs, qui à leur tour ont été connectés via une dérivation, pour faciliter la maintenance. Pour alimenter toute l'automatisation et la basse tension, de puissantes alimentations 2 volts ont été installées dans l'armoire, 2 par 12V et une par 5V. Depuis l'armoire d'automatisation, ils ont lancé des lignes de câbles 220V pour alimenter les ordinateurs et divers périphériques de la quête: de bouffée à bouffée à viu-viu))



Les solutions restantes sont assez standard pour de tels projets. Système de vidéosurveillance sur caméras IP filaires, toujours avec éclairage IR et microphones intégrés. Le flux vidéo est utilisé dans l'une des tâches de quête et est en outre traité sur le PC du gestionnaire de quête; un logiciel open source (ZoneMinder) est utilisé. Le réseau local de contrôleurs Arduino a été séparé du reste des réseaux afin que le flux des caméras ne charge pas les puces W5100 déjà faibles des cartes Ethernet.

Mains libres avec les participants au jeu utilisant un amplificateur soviétique conventionnel et des haut-parleurs de plafond intégrés.

Au final, je voulais décrire un petit serveur central. La plate-forme ioBroker est déployée sur la carte unique BananaPi ARM, dont la puissance s'est avérée suffisante pour toutes les tâches. L'environnement est le système d'exploitation Armbian, quelques scripts bash pour travailler avec GPIO et pour créer des sauvegardes dans le cloud sur Yandex.Disk. Plusieurs GPIO sont utilisés pour indiquer l'état de fonctionnement de chaque module et adaptateur (LED) et un bouton pour éteindre correctement le système. Sur la photo de l'armoire 19 pouces ci-dessus, on peut voir que la carte est dans un boîtier standard en plexiglas bon marché; plus tard, elle a été installée dans un boîtier 1U avec une alimentation électrique normale et d'autres périphériques.

Bugs, pièges, difficultés

Mes collègues et moi avons pensé à l'avance à l'architecture de base (j'ai fait le projet) et de nombreux nœuds ont été assemblés et testés «sur la table», il n'y a donc pas eu de changements fondamentaux. Des «rugosités» mineures ont été corrigées sur place. Les principaux problèmes, dont la solution a pris beaucoup de temps:

1. Manque de mémoire Arduino sur la puce 328, se déplaçant vers la carte Arduino MEGA. On pouvait s'y attendre reposait sur certains contrôleurs dans la mémoire de la puce. La plupart du temps a été consacré à retravailler les cartes d'extension.
2. Les problèmes de travail avec le pilote MQTT ont été résolus assez rapidement par l'auteur du projet ioBroker.
3. Le processus long et difficile de sélection d'un navigateur pour la visualisation normale dans le pilote VIS. Il s'est avéré difficile de travailler avec cet adaptateur. En conséquence, la modification a été effectuée dans le navigateur Chrome et l'opérateur d'exécution a lancé une version spécifique via le navigateur Dragon. Comme les bugs ont été corrigés, ils ont complètement migré vers le dernier navigateur Chrome.
4. Création progressive de solutions anti-vandalisme - micro-interrupteurs abandonnés, boutons et poussoirs mécaniques, claviers à film, etc.
5. Les serrures électromécaniques du shérif se sont avérées être de très mauvaise qualité; elles ont dû être remplacées localement par des serrures électromagnétiques ordinaires.
6. Le fonctionnement instable des contrôleurs Arduino lors du travail avec des caméras IP, en conséquence, les réseaux étaient divisés et tout fonctionnait comme il se doit.

Conclusion

L'ensemble du projet, de l'étude et de l'accord sur le scénario au lancement des premiers groupes de test, a pris environ six mois - beaucoup, mais c'était la première expérience et, de plus, j'ai presque suivi le principal travail de construction / rénovation des locaux. De plus, il y avait beaucoup de travail "sur la table" - principalement lors de l'utilisation de modules Arduino séparés, car ils ne fonctionnaient pas exactement comme je m'y attendais. Lors de la mise en œuvre du projet, nous avons essayé autant que possible d'adhérer aux principes suivants:

1. Le projet impliquait de la maintenance et des réparations mineures par tout ingénieur qui tenait au moins une fois un fer à souder dans ses mains, savait ce qu'était l'Arduino et serait en mesure de «clignoter» la LED soudée sur la carte.
2. Développement en Arduino IDE utilisant des bibliothèques standard pour une simplicité maximale.
3. Maximisez l'utilisation de modules communs sur étagère dans un projet pour faciliter la maintenance et le remplacement
4. Utiliser des protocoles et des réseaux de données standard
5. Minimisez le nombre de pièces mécaniques pour plus de durabilité et d'anti-vandalisme.

En conséquence, au cours des deux premières semaines, il s'est avéré qu'il éliminait tous les défauts mineurs et maintenant le système fonctionne depuis près de 4 ans dans presque l'environnement initial.