Всем привет, на Хабре уже есть несколько статей про автоматизацию игр типа «квесты в реальности» (раз, два, три, четыре, пять...), я хотел бы тоже поделиться своим опытом участия в подобном проекте. В далеком 2015 году мои друзья решили организовать квест типа escape-room «Ограбление банка» в нашем городе. Они знали, что я давно увлекаюсь различной автоматикой, в том числе системами типа «умный дом» на базе open source решений, поэтому попросили помощи в организации игры. Мне эта идея показалось интересной и я согласился — хотелось применить свой опыт и решения для чего то более интересного, чем поморгать лампочкой у себя в квартире.

Я постарался принять участие в полном цикле реализации проекта — от внесения правок в сценарий до последующей обкатки задач, выявления и исправления багов, последующие доработки. Я посетил несколько игр у нас в городе (в 2015 их можно было пересчитать по пальцам одной руки), не для фана, а скорее для получения опыта и реверс-инжиниринга решений, и это было хорошо заметно по реакции организаторов. Но после участия в игре в Москве, я понял настоящий масштаб «бедствия» и мне сильно захотелось сделать не хуже с технической стороны свою работу. Итак, квест «Ограбить банк» в г. Твери, за подробностями как он создавался и развивался в течении нескольких лет прошу под кат.

Описание технических решений

После того, как мои коллеги объяснили мне на пальцах, что от меня хотят и как всё должно работать, у меня в голове буквально за пару минут сформировалась архитектура: центральный сервер с платформой ioBroker, локальные контроллеры на базе плат и модулей Arduino, обмен данными с сервером и между контроллерами по протоколу MQTT. В итоге архитектура получилась примерно следующая:


Помимо взаимодействия контроллера задачи с центральным сервером, нужно было наладить взаимодействие между контроллерами разных квестовых задач. Для этого, по моему мнению, идеально подходил протокол MQTT с брокером на центральном сервере. Клиенты — контроллеры публикуют на сервер свои состояния, подписываются на команды от сервера и состояния других контроллеров. Для реализации этого решения был использован адаптер MQTT — он одновременно был и MQTT брокером и позволял создать иерархию топиков в дереве объектов ioBroker, чтобы использовать данные для визуализации и управления (скриншот ниже еще старой версии “админки”).


Впоследствии я не пожалел, что выбрал именно такое решение:

1. MQTT — легковесный протокол, библиотека занимала мало места и его с лихвой хватало даже на Arduino UNO с чипом ATmega328
2. При перезагрузке или первом включении контроллеров они по MQTT получали начальные условия старта работы — очень удобно
3. Это решение оказалось самым надежным из опробованных и довольно простое для реализации и изучения новичку

По потокам данных получается всего несколько вариантов, самый простой из них — в контроллере задачи №1 возникает событие (нажали кнопку), он публикует в определенный топик состояние кнопки и ее состояние отображается изменением цвета графического элемента на визуальной форме АРМ оператора.


Не менее простой и обратный вариант — нужно вручную включить реле через контроллер задачи №1, подается управляющее событие через VIS-адаптер, который меняет состояние топика этого контроллера, причем с ask=false. Адаптер MQTT получает изменение топика с ask=false, значит этот топик не от контроллера прилетел, соответственно происходит публикация изменения в контроллер, который в свою очередь публикует в ответ подтверждение с ask=true.


Межконтроллерный обмен происходит по событию на одном из контроллеров. К примеру, первый контроллер отработал свою задачу и должен включить реле на втором контроллере — он публикует в общий топик свой статус, брокер отображает его в дереве и на страничке визуализации, так как второй контроллер подписан на этот топик, брокер публикует его во второй контроллер и последний в свою очередь публикует в ответ подтверждение.


В проект еще нужно было добавить задачу взаимодействия с компьютером. Интерфейс был написал на php, страничка крутилась на WEB-сервере с автозапуском в полноэкранном режиме браузера. Интеграция с основной системой осуществлялась посредством драйвера simple-api — через php просто дергались определенные http-запросы к ioBroker. Сам системный блок был спрятан в недрах офисного стола, управление интерфейсом осуществлялось мышкой, а беспроводная клавиатура была у диспетчера квеста.

Визуализация для оператора была разработана в драйвере VIS для одного разрешения — монитора оператора, но впоследствии сотрудники квеста смогли пользоваться и мобильными планшетами с этим же интерфейсом, оказалось удобно для сброса при подготовке к новой игре и для диагностики системы. Интерфейс получился спартанский, без модных дашбордов и рюшек-переключателей, но зато понятный, простой и быстрый. Особенной логики, слоев, графиков и прочего в интерфейсе не нужно было, только иконки для отображения состояния оборудования, кнопки для управления и несколько текстовых полей для вывода режима работы контроллеров и лога работы системы.


На момент разработки проекта других вариантов оформления визуализации особенно и не было. Позже появились адаптеры визуализации как для мобильных устройств (я использую material), так и для стационарных планшетов/компьютеров: habpanel, lovelace, tileboard и другие.
Основная логика была заложена в коде контроллеров, но общее взаимодействие, инициализация параметров для запуска, сервисные функции и пр. — реализовано на основном сервере с помощью адаптера javascript. Код писался на JS с использованием встроенных функций ioBroker с последующим «переездом» на blockly (этот функционал появился позднее начала работ по проекту).


Всего было задействовано несколько скриптов:

1. скрипт для первоначальной инициализации системы (первое включение)
2. скрипт сброса всех контроллеров перед очередной игрой
3. один из контроллеров не сразу «переехал» на MQTT, поэтому некоторое время использовался скрипт для обмена с контроллером через HTTP — GET запросы
4. скрипт для ведения отдельного лога хода игрового процесса

Все контроллеры на базе плат Arduino UNO (впоследствии несколько контроллеров пришлось переделать под платы Arduino MEGA — не хватало памяти) оснащались платой расширения Ethernet на базе чипа W5100. Обмен данными между контроллерами и сервером (как писал выше) по протоколу MQTT. Разработка алгоритмов в Arduino IDE велась с использованием стандартных библиотек. По железной части ничего сверхъестественного — максимальное использование готовых модулей и плат расширения с минимумом пайки и без изготовления кастомных плат — всё на макетных платах. Управление нагрузками через модули с реле обычными и твердотельными, транзисторные ключи для светодиодов индикации и маломощной нагрузки. По механической части старался как можно меньше применять подвижные элементы: микровыключатели, толкатели, Э/М замки и больше использовать готовые модули светодиод-фотодиод (открытые оптопары), твердотельные реле, обычные магнитные замки, считыватели бесконтактных карт и герконовые датчики. Несколько фото ниже:





Питание контроллеров на месте осуществлялось через самодельные POE-переходники — по витой паре незадействованные жилы «вещали» 12В постоянного тока. Преобразование на платах контроллеров через готовые платы DC-DC до 5В — от которых питались сами платы Arduino + Ethernet и маломощная нагрузка с логикой 5В: слаботочные светодиоды, реле и пр. Более мощная нагрузка 12В: магнитные замки, мощные реле или контакторы, различная светотехника — использовались отдельные кабельные линии проводом ШВВП или ПВС. В основной шкаф автоматики подвели два ввода 220В переменного тока и через АВР на контакторах подключили ИБП, который в свою очередь был подключен через байпас, для удобства обслуживания. Для питания всей автоматики и слаботочки, в шкафу установили мощные блоки питания 2 по 12В и один на 5В. От шкафа автоматики пустили кабельные линии 220В для питания компьютеров и различной периферии квеста: от пых-пых до виу-виу))



Остальные решения довольно стандартные для подобных проектов. Система видеонаблюдения на проводных IP-камерах, обязательно с ИК-подсветкой и встроенными микрофонами. Видеопоток используется в одной из задач квеста и дополнительно обрабатывается на ПК диспетчера квеста, используется open source программное обеспечение (ZoneMinder). Локальную сеть контроллеров Arduino отделили от остальных сетей, чтобы поток от видеокамер не нагружал и без того слабые чипы W5100 ethernet-плат.

Громкая связь с участниками игры с использованием обычного советского усилителя и встроенных потолочных динамиков.

В конце хотел описать немного центральный сервер. Платформа ioBroker развернута на ARM-одноплатнике BananaPi, мощности которого оказалось достаточно для всех задач. Окружение — операционная система Armbian, пару bash скриптов для работы с GPIO и для создания резервных копий в облако на Яндекс.Диск. Используются несколько GPIO для индикации состояния работы отдельных модулей и адаптеров (светодиоды) и кнопка для корректного выключения системы. На фото 19” шкафа выше видно, что плата в стандартном дешевом корпусе из оргстекла, впоследствии она была установлена в 1U корпус с нормальным блоком питания и прочей периферией.

Баги, подводные камни, трудности

Основную архитектуру мы с коллегами довольно хорошо продумали заранее (я делал проект) и многие узлы удалось собрать и протестировать «на столе», поэтому кардинальных изменений не было. Мелкие «шероховатости» исправлялись на месте. Основные проблемы, решение которых заняло довольно много времени:

1. Нехватка памяти Arduino на чипе 328, переезд на плату Arduino MEGA. Предсказуемо уперся по некоторым контроллерам в память чипа. Основное время ушло на переделку плат расширения.
2. Глюки в работе с MQTT-драйвером довольно оперативно решались автором проекта ioBroker.
3. Долгий и непростой процесс подбора браузера для нормальной работы визуализации в драйвере VIS. Оказалось непросто работать с этим адаптером. В итоге редактирование осуществлял в браузере Chrome, а runtime оператор запускал через браузер Dragon определенной версии. По мере исправления ошибок, полностью переехали на браузер Chrome последней версии.
4. Постепенное создание антивандальных решений — отказывались от микровыключателей, механических кнопок и толкателей, пленочных клавиатур и т.п.
5. Электромеханические замки «Шериф» оказались очень низкого качества, приходилось по месту менять на обычные электромагнитные замки.
6. Нестабильная работа контроллеров Arduino при работе IP-камер, в итоге разделили сети и всё заработало как надо.

Заключение

Весь проект от изучения и согласования сценария до запуска первых тестовых групп занял около полугода — да много, но это был первый опыт и к тому же, я почти не отставал от основных работ по стройке/ремонту помещений. Плюс к тому, было много работы «в стол» — в основном при использовании отдельных модулей Arduino, потому как они работали не совсем так, как я предполагал. При реализации проекта максимально старались придерживаться следующих принципов:

1. Проектом подразумевалось обслуживание и мелкий ремонт любым инженером, который хоть раз держал в руках паяльник, знает что такое Arduino и сможет «поморгать» распаянным на плате светодиодом.
2. Разработка в Arduino IDE с использованием стандартных библиотек для максимальной простоты.
3. Максимальное использование готовых, распространенных модулей в проекте для простоты обслуживания и замены
4. Использовать стандартные протоколы и сети передачи данных
5. Максимально уменьшить количество механических деталей для долговечности и антивандальности.

По итогу, в первые пару недель получилось избавиться от всех мелких недостатков и сейчас система почти в первоначальном окружении работает уже больше 4-х лет.