Pull to refresh

Comments 23

Ходил на такие квесты — понравилось. Задавался вопросом, как такое может быть устроено, а тут как раз такая статья! Спасибо!
Несколько вопросов:
У вас в квестах только «электрическая» логика реализована? Я, например, сталкивался с заданием, где была проволока из материала с памятью — при нагреве она изменяла положение и становилась цифрой, которая нужна для кода.
Кто и как придумывает квесты и задания к ним?
В какой IDE пишете для Arduino?
Ссылок на фирму, для которой делаете квесты, не будет? :)
P.S. Порадовался за ссылку на chipster — сам им пользуюсь :)
У нас пока только электрическая: микроконтроллеры, датчики и т.п. Но да, бывают и другие, например, надпись, которая проявляется при нагреве.

Задания придумывает заказчик вместе со специально нанятыми сценаристами.

Конкретно этот проект писался в vim и Qt creator. Но отладчиком не пользовались, поэтому разницы особой нет.

В квесте который я «обардуинивал» все «событийные» провода (по моей же просьбе) были выведены в операторскую, в щиток, получилось весьма компактно и удобно. Особенно в плане отладки. В центре ардуина мега, задействованы почти все пины. Помимо управления силовыми цепями (реле, диммеры), так же по событиям ардуина играет квестовые звуки (через платку DF Robot MP3). При этом сделана разводка по динамикам, т.е. звук идёт не по всей локации, а именно оттуда где случилось игровое событие (реализовано переключением реле, щелчков нет).
Оператор видит ход игры и может, при необходимости, вмешаться в процесс (кнопками).
Такое решение возникло при начальном строительстве или при «рефакторинге»?
При начальном.
Это был изначально новый квест, и для товарищей которые делали квест — использование электроники было впервые (раньше все делали на реле/реле с задержками). Мысль насчёт ВПУ даже не рассматривалась, но была принята легко и радостно.
Когда обратились ко мне с этим вопросом, я изначально задал задачу сделать ВПУ (выносной пульт управления), во-первых имея опыт работы в оборонке — это офигенски удобная вещь, во-вторых — это было бы убийство чистой воды заводить всё это за стену и делать отладку там же впотьмах, ограниченном пространстве и ограниченном времени (буквально до нескольких минут).
Даже если какой косяк электроники — оператор может поправить всё кнопками. Например частично восстановить логику квеста после пропадания электричества (естественно, когда «постреляли» все магнитные замки — тут кнопками не обойдёшся).

Но гемороя, по моему недосмотру, это доставило тоже неслабо, т.к. все провода и силовые и сигнальные были брошены одним пучком, а когда пришёл я с ардуиной — было уже поздно…

Кстати по ходу строительства и отладки аппетиты росли, функционал тоже рос, заложенных проводов и запаса не хватало :)

И на самом деле были использованы три ардуины:
— мега в щитке;
— уно, прикидывающаяся клавиатурой и управляющая андроидной ТВ-приставкой;
— и ещё маленькая pro mini, прикидывающаяся нокией 3310 (даже с парсингом rtttl) :)
судя по иксам, вы «выход»цы?
Небольшое замечание — при работе в arduino ide ничто не мешает вам пользоваться полным комплектом периферии атмеги, в том числе — таймерами. Просто не надо вызывать функции, так или иначе, задействующие данный элемент. Весь синтаксис ардуино — всего-лишь надстройка в виде библиотек поверх стандартного gcc
Я имел в виду, что некоторые прерывания уже заняты. Например, millis() использует для работы значение, изменяющееся в timer0_ovf_vect, если не ошибаюсь.

Возможно, можно было и оставить их код целиком, каким-то образом доработав. Но поскольку хотелось минимизировать источники неожиданных моментов (а куча чужого кода является таким источником) и обеспечить максимальную гибкость, было принято решение использовать «мини-ядро».
Ну, если вы ни разу не вызывали в коде эту функцию, то таймер она и не займет. То есть, если знаешь что и как работает и понимаешь, чем «платишь» за ту или иную функцию, то никаких проблем быть не должно.
Это так, просто замечание.
А статья хорошая. Приятно что кто-то стремится к порядку! Именно поэтому я не люблю квесты: «лишь бы как-то работало. Трогать не будем, авось и не развалится».
Спасибо) На самом деле, это только начало, в железном плане там как обычно каша и кучи проводов.

P.S. ISR всегда забивается кодом arduino, см. [arduino]/hardware/arduino/avr/cores/arduino/wiring.c
image

Поставить свой код нельзя:

image
Если честно, то неудивительно, что обрывы проводов часто случаются. Используйте кабель каналы, стяжки, органайзеры для проводов, щиты, шкафы для оборудования, и, я думаю, большинство проблем уйдёт. Так же советую обратить внимание на расшивочные панели KRONE, вместо использования одиночных болтающихся клемников.
image
М-да, до такой крутизны мне еще далеко. Но уже успел столкнуться с проблемой. азбука Морзе, что мигает на втором мониторе, не соответствует тем кодам, что должны быть. Хотя дома на компе все ок. Реализовывал мигание на Sleep'ах. Может кто из с++ программистов подскажет, где загвоздка? Сам я еще начинающий.
А не пробовали использовать беспроводные модули? Или решения для автоматизации и «умного дома».

Площади таких квестов, как правило, небольшие, сигнал должен «ходить» отлично. Распространенный nrf24l01 (usb-свисток в сервере и пачка на конечных точках) должен вполне бюджетно решить задачу. А дальше использовать любой удобный язык на сервере и минимальную «железную» конфигурацию на концах — драйвер + датчик.

Или еще вариант — использовать шинный интерфейс для уменьшения кол-ва проводов (I2C?).
Не хотелось жертвовать стабильностью, все-таки, провода, тем более — Ethernet, стабильнее, чем воздух и этот чип.

Мы смотрели, I2C не хватит по длине. Хотели использовать RS-485, но там возни с проводами больше, чем в ethernet. Тут просто вставил и оно заработало, а там нужно разбираться с терминаторами. Также пришлось бы придумывать что-то с выдачей адресов, диагностикой и т.п., а тут уже готовые DHCP и ping.

Думали насчет умного дома, но, опять же, захотелось гибкости. Очень нехорошо бы вышло, если бы сделали все на умном доме X, а потом бы оказалось, что новая фича от заказчика нереализуема на нем.
Судя по задачам — описываются игры разума %)
У нас квест сработал нормально, а вот у наших товарищей что-то постоянно глючило, не срабатывало.
Стабильно работает avr-etherboot? Косяки с ним часто случаются? Пытаюсь централизировать умный дом, думал использовать ZigBee, но решился прокинуть провода сразу с питанием датчиков. Если можно посмотреть код, особенно изербута, было бы здорово.
На нашей памяти (Ноябрь 2014-Август 2015) avr-etherboot ни разу не глючил.
Он в открытом доступе есть же. Какой конкретно код вас интересует?
Это круто! Спасибо за статью и за ответ!

Если кому-то понадобится код, я создам публичный репозиторий. Основной закрыт, т.к. в нем содержится сценарий и другие секретные штуки.


В частности работу с Мегой через UDP с использованием изербута
Всегда пожалуйста

Понял. На следующей неделе выложу внизу статьи ссылку на репозиторий с кодом avr-etherboot для Arduino Mega, а также укажу в README, как этим пользоваться.

Работа с мегой через UDP очень простая: мы просто получаем и принимаем пакеты средствами библиотеки EtherCard.
Дополнительный трюк: делаем геттер для буфера данных библиотеки и при приеме/отправке читаем/пишем сразу туда, без «лишнего» буфера в коде вне библиотеки.

Если нужно, могу этот код тоже выложить.
Снова привет! Наконец дошли руки и что-то заработало, но есть проблема с питанием платы enc от ардуины, часто enc виснет и приходится все перезагружать… У меня модуль немного по-другому выглядит, но суть та же (не такой как у вас в статье на картинке, питается от 3.3В). Поделитесь пожалуйста вашим методом подключения enc и питания, если не сложно?
У нас enc нормально питается от Arduino. Хотя формально ток enc больше допустимого тока на пине 3.3В, регулятор остается холодным. В какой момент происходит зависание? Старые версии драйвера висли при большом потоке пакетов.
Большая часть поломок в квесте, из-за которых приходится отменять игры — не проблемы в коде или логике, а банально отвалившиеся провода.

Радиотехника — наука о плохих контактах.
Sign up to leave a comment.