Iobroker-Suche nach Quests in Reality-Spielen

Hallo allerseits, es gibt bereits mehrere Artikel über Habré über die Automatisierung von Spielen wie "Quests in Reality" ( eins , zwei , drei , vier , fünf ...). Ich möchte auch meine Erfahrungen mit der Teilnahme an einem solchen Projekt teilen. Im Jahr 2015 beschlossen meine Freunde, eine Fluchtraum-Quest „Banküberfall“ in unserer Stadt zu organisieren. Sie wussten, dass ich schon lange verschiedene Automatisierungen mochte, darunter Systeme wie "Smart Home", die auf Open Source-Lösungen basieren, und baten um Hilfe bei der Organisation des Spiels. Diese Idee schien mir interessant und ich stimmte zu - ich wollte meine Erfahrungen und Lösungen für etwas Interessanteres einsetzen, als eine Glühbirne in meiner Wohnung zu blinken.

Ich habe versucht, am gesamten Zyklus des Projekts teilzunehmen - von Änderungen am Skript bis zu den nächsten Einlaufaufgaben, dem Erkennen und Beheben von Fehlern und nachfolgenden Verbesserungen. Ich habe mehrere Spiele in unserer Stadt besucht (2015 konnten sie an den Fingern einer Hand gezählt werden), nicht für den Fan, sondern um Erfahrungen zu sammeln und Lösungen zurückzuentwickeln, und dies wurde durch die Reaktion der Organisatoren deutlich sichtbar. Aber nachdem ich in Moskau am Spiel teilgenommen hatte, verstand ich das wahre Ausmaß der „Katastrophe“ und wollte meinen Job wirklich nicht schlechter machen als die technische Seite. Bei der Suche nach „Rob the Bank“ in Tver nach Einzelheiten darüber, wie es im Laufe mehrerer Jahre geschaffen und entwickelt wurde, frage ich nach Katze.

Beschreibung der technischen Lösungen

Nachdem meine Kollegen mir an den Fingern erklärt hatten, was sie von mir wollen und wie alles funktionieren sollte, nahm in meinem Kopf buchstäblich in wenigen Minuten eine Architektur Gestalt an: ein zentraler Server mit ioBroker- Plattform, lokale Controller auf Basis von Arduino-Boards und -Modulen, Datenaustausch mit Server und zwischen Controllern, die das MQTT-Protokoll verwenden. Infolgedessen stellte sich heraus, dass die Architektur ungefähr wie folgt aussah:


Zusätzlich zur Interaktion des Task-Controllers mit dem zentralen Server musste eine Interaktion zwischen den Controllern verschiedener Quest-Aufgaben hergestellt werden. Hierfür war meiner Meinung nach das MQTT-Protokoll mit einem Broker auf einem zentralen Server ideal geeignet. Clients - Controller veröffentlichen ihre Status auf dem Server, abonnieren Befehle vom Server und die Status anderer Controller. Um diese Lösung zu implementieren, wurde der MQTT- Adapter verwendet - er war auch ein MQTT-Broker und ermöglichte es Ihnen, eine Hierarchie von Themen im ioBroker-Objektbaum zu erstellen, um die Daten für die Visualisierung und Verwaltung zu verwenden (ein Screenshot unter der alten Version des „Admin-Panels“).


In der Folge habe ich es nicht bereut, dass ich mich für eine solche Lösung entschieden habe:

1. MQTT ist ein leichtes Protokoll, die Bibliothek nahm wenig Platz ein und war selbst für die Arduino UNO mit dem ATmega328-Chip mehr als genug
2. Beim ersten Neustart oder Einschalten der Steuerungen erhielten sie die Anfangsbedingungen für den Beginn der Arbeit mit MQTT - dies ist sehr praktisch
3. Diese Lösung erwies sich als die zuverlässigste der getesteten und für Anfänger recht einfach zu implementieren und zu studieren

Nur wenige Optionen werden von Datenströmen erhalten, die einfachste davon - ein Ereignis tritt in Task-Controller Nr. 1 auf (eine Taste wird gedrückt), es veröffentlicht den Schaltflächenstatus in einem bestimmten Thema und sein Status wird angezeigt, indem die Farbe eines grafischen Elements in der visuellen Form des Bedieners geändert wird.


Eine ebenso einfache und entgegengesetzte Option besteht darin, dass Sie das Relais manuell über Task-Controller Nr. 1 einschalten müssen. Ein Steuerereignis wird über den VIS-Adapter bereitgestellt, der den Status des Themas dieses Controllers ändert, und mit ask = false. Der MQTT-Adapter empfängt eine Themenänderung mit ask = false, sodass dieses Thema nicht vom Controller eingetroffen ist. Die Änderung wird auf dem Controller veröffentlicht, der wiederum eine Bestätigung mit ask = true als Antwort veröffentlicht.


Der Intercontroller-Austausch erfolgt bei einem Ereignis auf einem der Controller. Beispielsweise hat der erste Controller seine Aufgabe erfüllt und muss das Relais auf dem zweiten Controller einschalten - er veröffentlicht seinen Status im allgemeinen Thema, der Broker zeigt ihn in der Baumstruktur und auf der Visualisierungsseite an, da der zweite Controller dieses Thema abonniert hat, der Broker veröffentlicht ihn auf dem zweiten Controller und Letzterer veröffentlicht seinerseits eine Bestätigungsantwort.


Das Projekt musste noch die Aufgabe der Interaktion mit einem Computer hinzufügen. Die Oberfläche wurde in PHP geschrieben, die Seite drehte sich auf einem WEB-Server mit Autorun im Vollbild-Browsermodus. Die Integration mit dem Hauptsystem erfolgte mit dem Simple-API- Treiber - bestimmte PHP-Anfragen an ioBroker zuckten einfach über PHP. Die Systemeinheit selbst war im Darm des Schreibtischs versteckt, die Schnittstelle wurde mit der Maus gesteuert und der Quest-Dispatcher verfügte über eine drahtlose Tastatur.

Die Visualisierung für den Bediener wurde im VIS- Treiber für eine Auflösung entwickelt - den Monitor des Bedieners. Anschließend konnten die Questmitarbeiter mobile Tablets mit derselben Benutzeroberfläche verwenden. Dies erwies sich als praktisch zum Zurücksetzen, um ein neues Spiel vorzubereiten und das System zu diagnostizieren. Die Benutzeroberfläche erwies sich als spartanisch, ohne modische Dashboards und Ryushek-Schalter, aber verständlich, einfach und schnell. Es waren keine spezielle Logik, Ebenen, Diagramme oder andere Elemente in der Benutzeroberfläche erforderlich, nur Symbole zur Anzeige des Gerätestatus, Schaltflächen zur Steuerung und mehrere Textfelder zur Anzeige des Betriebsmodus der Steuerungen und des Systembetriebsprotokolls.


Zum Zeitpunkt der Entwicklung des Projekts gab es keine anderen Optionen für das Visualisierungsdesign. Später erschienen Visualisierungsadapter sowohl für mobile Geräte (ich verwende Material ) als auch für stationäre Tablets / Computer: Habpanel , Lovelace , Tileboard und andere.
Die Hauptlogik wurde im Code der Steuerungen festgelegt, aber die allgemeine Interaktion, Initialisierung der Parameter zum Starten, Servicefunktionen usw. wurde auf dem Hauptserver mithilfe des Javascript- Adapters implementiert. Der Code wurde in JS mit den integrierten ioBroker- Funktionen geschrieben , gefolgt von einem "Verschieben" zum Blockieren (diese Funktionalität erschien später als der Beginn der Arbeit am Projekt).


Insgesamt waren mehrere Skripte beteiligt:

1. Skript für die anfängliche Systeminitialisierung (erste Aufnahme)
2. Skript zum Zurücksetzen aller Controller vor dem nächsten Spiel
3. Da einer der Controller nicht sofort zu MQTT "verschoben" wurde, wurde für einige Zeit ein Skript verwendet, um über HTTP-GET-Anforderungen mit dem Controller auszutauschen
4. Skript zum Verwalten eines separaten Protokolls des Gameplays

Alle auf Arduino UNO-Karten basierenden Controller (später mussten mehrere Controller auf Arduino MEGA-Karten umgestellt werden - es gab nicht genügend Speicher) waren mit einer Ethernet-Erweiterungskarte auf Basis des W5100-Chips ausgestattet. Datenaustausch zwischen Controllern und dem Server (wie oben beschrieben) unter Verwendung des MQTT-Protokolls. Die Entwicklung von Algorithmen in der Arduino IDE wurde unter Verwendung von Standardbibliotheken durchgeführt. Auf der Eisenseite gibt es nichts Übernatürliches - die maximale Verwendung von vorgefertigten Modulen und Erweiterungskarten mit einem Minimum an Löten und ohne die Herstellung von kundenspezifischen Platinen - alles auf Steckbrettern. Lastmanagement durch Module mit konventionellen und Halbleiterrelais, Transistorschaltern für LED-Anzeigen und Lasten mit geringem Stromverbrauch. Beim mechanischen Teil habe ich versucht, bewegliche Elemente so wenig wie möglich zu verwenden: Mikroschalter, Drücker, E / M-Schlösser und vorgefertigte LED-Fotodiodenmodule (offene Optokoppler), Halbleiterrelais, herkömmliche Magnetschlösser, Näherungskartenleser und Reedsensoren. Ein paar Fotos unten:





Vor-Ort-Controller wurden über hausgemachte POE-Adapter mit Strom versorgt - Twisted-Pair-Kabel verwendeten Leerlaufkerne, um 12-V-Gleichstrom zu übertragen. Konvertierung auf Controller-Karten durch vorgefertigte DC-DC-Karten bis zu 5 V - von denen Arduino + Ethernet-Karten selbst und Niedrigleistungslast mit 5 V-Logik gespeist wurden: Niedrigstrom-LEDs, Relais usw. Stärkere 12 V-Last: Magnetschlösser, leistungsstarke Relais oder Schütze, verschiedene Beleuchtungsgeräte - Separate Kabelleitungen wurden mit einer Kugelumlaufspindel oder einem PVA-Draht verwendet. Zwei 220-V-Wechselstromeingänge wurden in den Hauptautomatisierungsschrank gebracht, und eine USV wurde über Schütze an den Schützen angeschlossen, die wiederum über einen Bypass angeschlossen wurden, um die Wartung zu vereinfachen. Um die gesamte Automatisierung und Niederspannung mit Strom zu versorgen, wurden im Schrank leistungsstarke 2-Volt-Netzteile installiert, 2 x 12 V und 1 x 5 V. Vom Automationsschrank aus starteten sie 220 V-Kabel für die Stromversorgung von Computern und verschiedenen Peripheriegeräten der Suche: von Puff-Puff bis Viu-Viu))



Die restlichen Lösungen sind für solche Projekte ziemlich Standard. Videoüberwachungssystem für kabelgebundene IP-Kameras, immer mit IR-Beleuchtung und eingebauten Mikrofonen. Der Videostream wird in einer der Questaufgaben verwendet und zusätzlich auf dem PC des Questmanagers verarbeitet. Open Source-Software (ZoneMinder) wird verwendet. Das lokale Netzwerk der Arduino-Controller wurde vom Rest der Netzwerke getrennt, damit der Stream von den Kameras die bereits schwachen W5100-Chips von Ethernet-Boards nicht lädt.

Freisprechen mit Spielteilnehmern mit einem herkömmlichen sowjetischen Verstärker und eingebauten Deckenlautsprechern.

Am Ende wollte ich einen kleinen zentralen Server beschreiben. Die ioBroker-Plattform wird auf der BananaPi ARM-Einzelplatine bereitgestellt, deren Leistung sich für alle Aufgaben als ausreichend herausstellte. Die Umgebung ist das Armbian-Betriebssystem, ein paar Bash-Skripte für die Arbeit mit GPIO und für die Erstellung von Backups in der Cloud auf Yandex.Disk. Mehrere GPIOs werden verwendet, um den Betriebsstatus einzelner Module und Adapter (LEDs) anzuzeigen, und eine Taste, um das System korrekt auszuschalten. Auf dem Foto des 19-Zoll-Gehäuses oben ist zu sehen, dass sich die Platine in einem billigen Plexiglasgehäuse befindet, das später in einem 1U-Gehäuse mit normaler Stromversorgung und anderen Peripheriegeräten installiert wurde.

Bugs, Fallstricke, Schwierigkeiten

Meine Kollegen und ich haben die grundlegende Architektur ziemlich lange im Voraus durchdacht (ich habe das Projekt durchgeführt) und viele Knoten wurden „auf dem Tisch“ zusammengesetzt und getestet, sodass es keine grundlegenden Änderungen gab. Kleinere „Rauheiten“ wurden an Ort und Stelle behoben. Die Hauptprobleme, deren Lösung viel Zeit in Anspruch nahm:

1. Mangel an Arduino-Speicher auf 328-Chip, Umzug auf Arduino-MEGA-Karte. Vorhersehbar ruhte auf einigen Controllern im Chipspeicher. Die meiste Zeit wurde für die Überarbeitung der Erweiterungskarten aufgewendet.
2. Probleme bei der Arbeit mit dem MQTT-Treiber wurden vom Autor des ioBroker-Projekts ziemlich schnell behoben.
3. Der lange und schwierige Prozess der Auswahl eines Browsers für die normale Visualisierung im VIS-Treiber. Es stellte sich als schwierig heraus, mit diesem Adapter zu arbeiten. Infolgedessen wurde die Bearbeitung im Chrome-Browser durchgeführt, und der Laufzeitoperator startete eine bestimmte Version über den Dragon-Browser. Da die Fehler behoben wurden, wurden sie vollständig auf den neuesten Chrome-Browser verschoben.
4. Allmähliche Entwicklung von Anti-Vandalismus-Lösungen - aufgegebene Mikroschalter, mechanische Tasten und Drücker, Filmtastaturen usw.
5. Die elektromechanischen Schlösser des Sheriffs erwiesen sich als von sehr geringer Qualität, sie mussten lokal durch gewöhnliche elektromagnetische Schlösser ersetzt werden.
6. Der instabile Betrieb von Arduino-Controllern bei der Arbeit mit IP-Kameras führte dazu, dass die Netzwerke geteilt wurden und alles so funktionierte, wie es sollte.

Fazit

Das gesamte Projekt, vom Studium und der Vereinbarung des Szenarios bis zum Start der ersten Testgruppen, dauerte ungefähr sechs Monate - viel, aber es war die erste Erfahrung, und außerdem habe ich fast mit den Hauptarbeiten zum Bau / zur Reparatur der Räumlichkeiten Schritt gehalten. Außerdem gab es viel Arbeit "auf dem Tisch" - hauptsächlich bei Verwendung separater Arduino-Module, da diese nicht genau so funktionierten, wie ich es erwartet hatte. Bei der Umsetzung des Projekts haben wir versucht, die folgenden Grundsätze so weit wie möglich einzuhalten:

1. Das Projekt beinhaltete Wartung und kleinere Reparaturen durch jeden Ingenieur, der mindestens einmal einen Lötkolben in den Händen hielt, weiß, was Arduino ist und in der Lage sein wird, die auf der Platine gelötete LED zu „blinken“.
2. Entwicklung in Arduino IDE unter Verwendung von Standardbibliotheken für maximale Einfachheit.
3. Maximieren Sie die Verwendung von handelsüblichen Standardmodulen in einem Projekt, um die Wartung und den Austausch zu vereinfachen
4. Verwenden Sie Standardprotokolle und Datennetze
5. Minimieren Sie die Anzahl der mechanischen Teile, um Haltbarkeit und Vandalismus zu gewährleisten.

Infolgedessen stellte sich heraus, dass in den ersten Wochen alle geringfügigen Mängel beseitigt wurden, und jetzt funktioniert das System seit fast 4 Jahren in fast der ursprünglichen Umgebung.