Arduino

Пару лет назад я обзавёлся топовым смартфоном одной южнокорейской компании. Среди его особенностей оказалась поддержка DeX - способа запуска на большом экране, подключаемом к док-станции через HDMI, отдельных приложений и даже целого Linux в контейнере (к сожалению, последнее ушло со свежей версией Android). Кроме того, порадовала поддержка переферийных устройств - так, внешняя звуковая карта Asus Xonar U7, с которой у меня пущен сигнал на ресивер с большими колонками, завелась без проблем. Отсюда возникло желание превратить телефон в мини-рабочее место, научив делить переферию с системником - напирмер, чтобы вой кулеров не мешал слушать музыку или смотреть видео. По сути, требовалось KVM-решение, удовлетворяющее ряду хотелок. Так я познакомился с Arduino.

Требования

До этого у меня на столе "жил" простой четырёхпортовый USB-хаб с клавишей отключения. К нему были подключены проводные клавиатура и мышь, а также Web-камера. Камеру я обычно физически отключал от хаба вне времени использования (паранойя), а клавиша отключения на хабе оказалась удобна тем, что позволяла с комфортом чистить клавиатуру и мышь, не выдёргивая разъёмы и не выключая компьютер. Кроме того, в хаб периодически включался аппаратный менеджер паролей. Звуковая карта и принтер были подключены напрямую к разъёмам на системном блоке, и этим набор USB-переферии ограничивается. Все перечисленные устройства работают по стандарту USB 2.0. На док-станции присутствуют два порта USB той же версии.

Заводить отдельную клавиатуру для телефона, конечно же, не хотелось. Кроме того, я очень привык к удобной мыши Logitech G600 с двенадцатью хорошо прощупываемыми дополнительными кнопками под большим пальцем, обладающими тем преимуществом, что назначенные на них комбинации работают под любой операционной системой и даже в BIOS без установки дополнительного ПО. Поэтому я решил использовать существующие клавиатуру и мышь, но делить их между устройствами. Кроме того, должен существовать способ отключить их совсем. Звуковая карта тоже должна переключаться между хостами и отключаться (чтоб не жрала энергию в отсутствие питания от сети). Отключение камеры решено было внести в ту же систему. Принтер остался в стороне, поскольку смартфон не захотел с ним работать.

Таким образом был сформирован следующий список требований к "умному" USB-переключателю:

1. Клавиатура и мышь должны совместно переключаться между телефоном и системным блоком, а также отключаться.

2. Звуковая карта должна переключаться между устройствами и отключаться независимо от клавиатуры и мыши.

3. Камера должна подключаться к системному блоку и отключаться независимо от других устройств. Факт того, что камера сейчас подключена (даже если на ней самой не горит лампочка), должен привлекать к себе внимание (например, миганием светодиода).

4. Переключения могут производиться вручную (кнопками) или автоматически (логикой хаба, например, при отключении или подключении устройств).

5. Монитор переключается независимо от остальных устройств. Поскольку видеокарта и док-станция включены на разные его входы, это делается кнопкой на самом мониторе.

6. Под рукой должен быть хаб или USB-разъём на гибком проводе для подключения менеджера паролей к системному блоку. Это может быть простой удлиннитель, уходящий под стол.

7. Телефон может быть подключен к переключателю как через док-станцию с внешним питанием, так и напрямую (например, чтобы включать музыку во время мытья пола, когда на сетевом фильтре под столом и, соответственнно, на док-станции нет питания). Желательно иметь для подключения через док-станцию и напрямую разные интерфейсы, чтобы не выдёргивать каждый раз разъём из док-станции. Вместо телефона может также быть подключен ноутбук (если HDMI-кабель с док-станции вручную переключить на него же, получится полноценное рабочее место, пока стационарный компьютер на обслуживании).

8. Питание на переключателе и на подключенных к нему подчинённых устройствах должно присутствовать, если включено хоть одно хост-устройство (системный блок, док-станция или телефон).

9. Должна присутствовать индикация, показывающая текущее состояние коммутации.

10. Вся конструкция должна занимать не слишком много места на столе.

Из имеющихся на рынке решений мне на глаза попались KVM-переключатели, а также специализированные переключатели USB вроде этого. Все встреченные мной модели работали по принципу "всё или ничего", коммутируя все подключенные к ним устройства совместно. Мне же хотелось иметь возможность, например, слушать музыку с телефона во время создания образа системного диска с использованием клавиатуры и мыши, а также отключать камеру независимо от остальных устройств. Кроме того, было желание поковыряться и попробовать собрать что-то самостоятельно. Друг посоветовал посмотреть в сторону Arduino, и я начал изучение.

Элементная база

Моё первое представление, составленное со слов друга, сводилось к тому, что для решения моей задачи достаточно будет подключить к контроллеру один или несколько шилдов с достаточным количеством USB-разъёмов, кнопок и индикаторов, а потом запрограммировать контроллер так, чтобы обеспечить коммутацию пакетов USB. Это оказалось неверным по нескольким причинам.

1. Шилды с мастер-разъёмами USB предназначены для того, чтобы контроллер мог сам опрашивать подключенную к ним переферию, выступая ведущим устройством на шине. При этом непосредственно в формировании и разборе пакетов Arduino не участвует - это делает сторонняя микросхема.

2. Слэйв-разъёмы предназначены почти исключительно для прошивки и отдалки контроллера, а за коммуникацию по ним отвечает не сам контроллер, а отдельная микросхема, обеспечивающая конвертацию серийных протоколов и определяющаяся как COM-порт. Заставить её вместо этого представиться USB-хабом и начать пропускать пакеты от других устройств невозможно.

3. Сами контроллеры не применяются для коммутации пакетов, и я не уверен, что мне с моим нулевым опытом на этой платформе удалось бы решить эту задачу, равно как и что она вообще имеет решение.

В этот момент я понял, что придётся паять. Опыта самоделок такого уровня у меня не было - тем выше был соблазн попробовать.

Идея состояла в том, чтобы взять два обычных хаба USB 2.0 (в сборе либо в виде микросхем) и под управлением Arduino коммутировать связи между ними и внешними устройствами, добиваясь того же эффекта, как если бы я вручную перетыкал разъёмы. Прежде всего это касается пары сигнальных проводов, поскольку подачу питания можно организовать отдельно. Вооружившись каталогом одного из магазинов радиодеталей, я приступил к поискам подходящей элементной базы.

Найти контроллеры хабов USB в таком виде, чтобы их можно было распаять на плате, мне не удалось - возможно, потому, что я неправильно искал. Поэтому я просто зашёл в компьютерный магазин рядом с домом и купил два самых простых и дешёвых хаба. Дома я вскрыл корпуса, извлёк из них платы и удалил с них разъёмы. Остались небольшие (примерно 2 на 8 сантиметров) панели, которые можно спрятать в корпус устройства, соединив с остальными компонентами монтажным проводом.

С коммутирующими элементами мне повезло больше - на глаза попался переключатель шины FST3125. Он представляет собой четыре ключа, каждый из которых замыкает либо размыкает два вывода:

Подключив через него мышь, я с удовольствием обнаружил, что всё работает.

Несложный подсчёт показывает, что одной такой микросхемы достаточно для переключения пары выводов D+ и D- одного устройства USB между двумя источниками. Стало быть, для управления одним каналом коммутации требуется два бита (или два вывода ардуинки):

Тем не менее, напрямую подавать управляющий сигнал от контроллера к коммутатору мне не хотелось. Дело в том, что, помимо трёх нужных мне состояний ("отключено", "подключено к первому источнику", "подключено ко второму источнику"), такая схема подключения даёт возможность открыть все ключи одновременно (например, из-за ошибки в программе или во время загрузки, когда значения выходных сигналов ещё не выставлены), что приведёт к соединению шин данных сразу трёх устройств, два из которых являются ведущими. Чтобы избежать такого сценария, я вставил между ардуинкой и коммутатором аппаратную логику, исключающую возможность одновременного открытия всех ключей:

Инвертор перед нижним элементом "или" позволяет сигналу "SIDE" выбирать группу ключей, которая будет открыта. В то же время, высокий сигнал на входе "ON" отключает все ключи сразу.

В качестве контроллера я взял Arduino Nano. Питание на него я подал через пин +5V, а вообще подачу питания организовал через пятивольтовые механические реле V23079A1001B301 (почему не через полупроводники - расскажу ниже). Светодиоды взял первые попавшиеся - убедившись, что через 220-омные резисторы ток и яркость получаются адекватными. Управление яркостью светодиодов взяли на себя встроенные ШИМы контроллера.

Поскольку ножек у Ардуинки не хватало, управление светодиодами (а также некоторой другой логикой на плате, см. ниже) я организовал через микросхемы серии AC32 (на макетке пробовал сначала DIP-исполнение, а потом перешёл на SOIC). Кроме того, в нескольких местах используются инверторы - модели LS04.

Дизайн

Теперь нужно было определиться с тем, как мой умный хаб должен выглядеть и управляться. Я начал с дизайна хаба, лежавшего у меня на столе, и мысленно дополнил его недостающими элементами. Этот процесс показан на рисунке ниже.

Работать такое устройство должно было следующим образом. Пять разъёмов USB-A, расположенных столбиком, по проекту были объединены в четыре группы и управлялись четырьмя кнопками (на рисунке - справа). Первая группа (два разъёма) предназначалась для клавиатуры и мыши, вторая (один разъём) - для звуковой карты, третья (один разъём) - для камеры, четвёртая (один разъём) была оставлена про запас.

Под крышкой находились те самые два хаба, подключенные к ведущим устройствам через три разъёма USB-B, расположенные в верхнем торце устройства. Правый разъём предназначен для подключения к компьютеру и всегда связан с "правым" хабом. К левому и среднему разъёмам подключались телефон и док-станция: когда телефон подключен, "левым" хабом владел он, в противном случае хаб доставался док-станции. Верхний ряд светодиодов отображал состояние "сторон"-хабов: зелёный - подключено к постоянному устройству, оранжевый - подключено к портативному устройству (телефону), красный - отключено.

Светодиоды с правой и левой стороны от каждого разъёма показывали, к какой стороне он сейчас подключен (а также к какой стороне он подключится при изменении внешних условий, например, возвращении питания на данную сторону). Первые две группы устройств (клавиатуру, мышь и звуковую карту) можно было подключать к любой из сторон и отключать. Камеру - подключать только к правой стороне или отключать. Последний разъём подключался к порту, оставшемуся свободным на левом хабе, и тоже мог отключаться.

Этот проект был затем пересмотрен по нескольким параметрам.

1. Я решил, что все группы должны вести себя полностью одинаково - меньше будет путаницы. Это подразумевало, что камера сможет, как и прочие каналы, подключаться к каждой из сторон, а пятый разъём исчезнет.

2. Иллюминация было урезана - остались по два светодиода на группу, загорающиеся при подключении её к правой и левой стороне, соответственно. Цвета этих диодов хватает, чтобы отслеживать также статус сторон.

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

4. Я добавил два "аварийных" светодиода, тлеющих и иногда ярко вспыхивающих красным светом: первый напоминает, что камера в данный момент подключена, второй указывает, что звуковой карте может не хватать питания (об этом - ниже). Эти светодиоды органично вписались в соответствующие кнопки.

Фотографию пульта в работе, а также его относительного размера к основной плате я привожу ниже.

Кнопки работают наиболее очевидным способом: одиночные нажатия последовательно переключают соответствующий канал между состояниями "подключен к компьютеру", "подключен к телефону", "отключен". Длинные или множественные нажатия не используются.

Светодиоды расположены над каждой кнопкой попарно и отображают состояние данного канала. Левый светодиод горит, когда канал подключен к системному блоку, правый - когда он подключен к телефону. Зелёный сигнал означает, что устройство, к которому выполнено подключение, активно, красный - что напряжения на этом направлении нет.

Макетирование

Проект пережил две макетки, в сумме прожившие у меня на столе более полугода. Их фотографии я прикрепляю ниже.

Первый вопрос касался схемы подключения коммутирующих микросхем. Я использовал описанную выше аппаратную защиту от одновременного открытия ключей, причём клавиатура и мышь управлялись одной парой сигналов. Кроме того, я использовал эту же схему для переключения "левого" хаба между телефоном и док-станцией - правда, не по сигналу контроллера, а по наличию напряжения на разъёме подключения телефона.

Далее, нужно было выбрать схему подключения светодиодов. Поскольку 6 двуцветных светодиодов и 2 одноцветных - это 14 каналов, нечего было и думать подключить их напрямую к ардуинке - ног не хватило бы. Кроме того, мне хотелось поиграться с ШИМами, снизив яркость индикаторов каналов в простое, но зажигая их ярко при нажатии на любую кнопку. "Аварийные" светодиоды я решил заставить мигать - за 4.5 секундами тления должна была следовать яркая вспышка длительностью в полсекунды.

Arduino Nano предоставляет всего шесть ШИМов. Я распределил их следующим образом:

• Управление яркостью красной компоненты "левых" светодиодов;

• Управление яркостью зелёной компоненты "левых" светодиодов;

• Управление яркостью красной компоненты "правых" светодиодов;

• Управление яркостью зелёной компоненты "правых" светодиодов;

• Управление светодиодом "камера включена";

• Управление светодиодом "звуковой карте не хватает питания".

Таким образом, "аварийные" светодиоды подключены напрямую к контроллеру, а остальные - к выходам элементов "или", смешивающих сигнал яркости с сигналом подключения канала к соответствующей стороне.

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

Первая проблема была тривиальной и сводилась к нехватке питания. Как показал эксперимент, просто взять и подключить все четыре устройства к одному хабу нельзя: клавиатура и мышь в сумме потребляют до 300 мА, камера - до 440, звуковая карта - до 540, и это не учитываея питания самой схемы. (Напоминаю, что я решил ограничиться стандартом USB 2.0 с 500 мА на порт, пусть даже материнские платы обычно и разрешают чуть более высокое энергопотребление.) В итоге я решил подключить компьютер через два кабеля вместо одного, предоставив звуковой карте как самому прожорливому потребителю отдельную шину питания - это показалось проще, чем поднимать версию USB. Если же компьютер не выдаёт напряжения на USB-разъёмы, то питание предоставляется оставшимся хостом (телефоном или док-станцией): совместное использование всех устройств в такой конфигурации невозможно, но и юзкейза для подключения всей переферии при обесточенном компьютере я не придумал. Соответственно, "аварийный" светодиод звуковой карты должен мигать, если при питании не от компьютера включены она и что-то ещё.

Кстати, это освободило один интерфейс USB A на хабе, подключенном к компьютеру. Я использовал его для подключения генератора паролей.

Вторая проблема тоже была связана с питанием. "Плюс" с трёх различных источников я изначально планировал свести через диоды с общим катодом, но испытания на макетке показали, что те диоды, которые попались мне под руку, под максимальной нагрузкой давали просадку напряжения почти на целый вольт, что я счёл неприемлимым (стандарт USB допускает минимум в 4.75В). Вместо диодов я организовал подачу питания через механические реле - 30 мА "лишнего" тока на источник выглядели разумной платой за гарантированно равные потенциалы, хотя предполагаю, что опытные радиолюбители нашли бы решение получше.

Переход на реле, впрочем, вызвал другую, неожиданную проблему. Поскольку логика работы контроллера (как минимум, по части управления светодиодами) зависит от того, на какие из разъёмов типа B подано напряжение, эта информация должна быть каким-то образом подана на него. Не мудрствуя лукаво, я завёл эти напряжения на аналоговые входы ардуинки, подтянув к нулю через резисторы номиналом 33k. Это нормально работало с диодами, однако реле добавили задержку, равную времени срабатывания механики, между появлением напряжения на аналоговом входе и на пине +5V. В итоге контроллер получал питание от аналогового пина и зависал на старте. Для исправления ситуации оказалось достаточно поставить между вводом питания и аналоговым пином ещё один резистор, на 18k - теперь до подачи питания на пин +5V Arduino не хватало тока, чтобы включиться, и старт проходил нормально.

Первая макетка управляла коммутацией лишь сигнальных линий USB. Быстро выяснилось, что этого недостаточно: хабы "не замечали" перекоммутации, и переключение мыши, клавиатуры и звуковой карты на другое устройство затягивалось на десятки секунд (а иногда и вовсе не происходило). Стало очевидно, что нужно также отключать питание управляемых устройств, для чего на схему были добавлены ещё четыре реле: по одному на каждый канал и одно для обесточивания "левого" хаба при переключении между телефоном и док-станцией. В итоге алгоритм переключения стал выглядеть следующим образом:

1. Отключаем линии связи со "старым" ведущим устройством.

2. Отключаем питание.

3. Ждём две секунды.

4. Включаем питание.

5. Включаем линии связи с "новым" ведущим устройством.

В таком режиме переключение стало происходить чётко и быстро - как при ручном подключении соответствующих разъёмов. Правда, для управления реле пришлось выделить отдельные пины на контроллере, чтобы светодиод, отображающий состояние коммутации, не гас на время принудительного отключения - такое поведение несколько дизориентировало. Это привело к тому, что остальные компоненты пришлось "втискивать" в оставшиеся свободными выводы ардуинки - сменив клавиатуру на аналоговую и даже сведя входные напряжения от обоих кабелей, ведущих к системному блоку, на один пин.

Ещё одной проблемой макеток были небольшие потери пакетов высокоскоростных устройств - изредка выпадали кадры с камеры, а в колонках при работе с телефона раздавались щелчки. Эти проблемы удалось нивелировать, сократив длину монтажного провода и, где возможно, подключив разрезанные USB-кабели напрямую к коммутаторам вместо распайки разъёмов USB-A и USB-B на макетке.

Итоговый проект

Финальная структурная схема коммутации линий данных выглядит следующим образом:

Здесь все переключатели с K1 по K5 представлены микросхемами FST3125. K1 и K2 управляются совместно, остальные - независимо. K1..K4 переключаются сигналами с контроллера, K5 - наличием напряжения на разъёме USB B, к которому подключается телефон.

Разводка питания выполнена по следующей схеме:

Земля (на схеме опущена) на всех разъёмах и на плате общая. Переключатели с K6 по K11 - это реле V23079A1001B301. Легко видеть, что питание схемы и большей части переферии обеспечивается системным блоком, если он выключен - то док-станцией, а в крайнем случае - телефоном. Для этого реле K6 и K7 управляются напрямую наличием питания на соответствующих разъёмах.

Реле K8..K11 управляются контроллером и используются для временного отключения устройств при переключении (переферии - между ведущими устройствами, первого хаба - между телефоном и док-станцией). Нагрузка подключена на их нормально замкнутые контакты, чтобы не увеличивать пиковый ток за счёт обмоток. Звуковая карта имеет приоритетное питание напрямую от системного блока.

Для создания финальной схемы и разводки дорожек я использовал EasyEDA, расположив элементы таким образом, чтобы минимизировать длину дорожек, по которым идут данные USB. Размеры платы я подогнал под пластиковый корпус, купленный в местном радиомагазине. Пульт собрал в отдельном маленьком корпусе и соединил с основной схемой жгутом монтажного провода, затянутом в термоусадочную трубку.

Плату я заказал в Китае. В готовом виде она выглядит следующим образом:

Правда, тут вышла небольшая накладка: распределяя пины контроллера для упрощения разводки, я случайно поменял местами пин с ШИМом и пин без него. В итоге управление яркостью светодиодов на одном из каналов стало невозможным. К счастью, это была единственная крупная ошибка, и я решил проблему, перерезав пару дорожек и соединив их крест-накрест монтажным проводом. Кроме того, я несколько неверно разметил выводы для подключения светодиодов, но это решилось иной распайкой проводов с пульта заменой номера пинов в программе.

Неприятным сюрпризом стали проблемы с потерей пакетов с камеры. Вскоре выяснилось, что пакеты теряются, только если камера подключена к хабу, соединённому с компьютером без промежуточной логики. При подключении через второй хаб, соединённый с ведущими устройствами через коммутатор FST3125, потерь не было. Не было их также и при переключении камеры на разъём, предназначенный для звуковой карты и подключенный к системному блоку в обход хабов. Наконец, подключив хаб напрямую к компьютеру обрезком USB-кабеля (а не через разъём USB-B, распаянный на плате), я снова добился отсутствия потерь.

Таблица ниже содержит информацию о том, в каких случаях наблюдались потери пакетов.

Из этой таблицы становится ясно, что потери пакетов наблюдаются только в том случае, если после разъёма USB B, в который включен кабель, пришедший с компьютера, следует отрезок провода, ведущий на плату хаба, причём между двумя этими отрезками нет микросхемы-коммутатора. По-видимому, кабель USB и перемычка из монтажного провода обладают разными волновыми сопротивлениями, что ведёт к появлению отражений на их границе и, соответственно, к потере пакетов. Микросхема FST3125, включенная между этими отрезками, эффективно гасит подобные отражения.

Чтобы проверить эту теорию, я соединил хаб с основной платой не монтажным проводом, а отрезком того самого кабеля, которым он далее подключен к компьютеру через разъём USB B. Результат превзошёл все ожидания: потери кадров полностью прекратились, и всё заработало как часы.

Плату я разместил в пластиковом корпусе, закрепив двумя гайками и прорезав окошки для разъёмов. Контроллер поставил в колодки, чтобы иметь возможность извлечь его для обновления прошивки. Хабы подвесил на проводах - они прижаты к верхней крышке корпуса их жёсткостью, что не должно создавать проблем. Сам корпус я подвесил на шнурке к креплению настольной лампы, а пульт положил на стол. Разъёмы подписал белым маркером.

Программа написана на C++ и доступна по ссылке. Я постарался разделить сущности, отвечающие за взаимодействие с различными компонентами схемы, хотя и поленился выделить код методов в файлы cpp, рассудив, что система сборки Arduino Studio всё равно не извлечёт из этого какой-либо выгоды. За работу с кнопками (прежде всего, антидребезг) отвечает библиотека GyverButton. За тайминг (отключение устройств, мигание и снижение яркости светодиодов) - GyverTimer. И то, и другое достпно в пакете GyverLibs - пользуясь случаем, выражаю его автору свою благодарность.

Резюме

Задача оказалась хорошей в учебном плане - благодаря работе над проектом я обрёл новые навыки и знания. Это касается как работы с железом (раздача питания, коммутация потоков данных, управление индикацией, пайка микросхем в форм-факторе SOIC, отражения в высокочастотном тракте), так и представлений о современных контроллерах и способах их использования. Получившееся изделие прекрасно справляется со своей задачей - использование телефона в качестве рабочего места или источника музыки происходит теперь весьма просто.

В то же время, существующее железо для Arduino не позволило пойти по пути быстрого прототипирования, поскольку многое пришлось изобретать самому, что сильно затянуло проект. Надеюсь, следующую задумку - управление работой дистиллятора - удастся реализовать более прямым путём.

Для нетерпеливых - ссылка на видео с демонстрацией и полным контентом поста в конце

Одной из распространенных привычек среди мультиинструменталистов, когда дело доходит до игры на стандартной фортепианной клавиатуре, является попытка применить выразительность других классов инструментов к простым вкл/выкл переключателем синтезатора, как правило, без какого-либо эффекта. Это распространяется и на другие музыкальные периферии, иногда более подходящие для таких манипуляций.

Обычно МИДИ клавиатуры оснащены питчбенд колесами, сенсорными полосками или джостиками, но они редко производят естественно звучащий результат и оккупируют одну из рук полностью. Именно по причине неестественности звучания одна из осей джойстика как правило привязана к вибрато.

Не удивительно, что на рынке полно устройств, которые преобразовывают это усилие в язык музыки. Первый это Roli Seaboard, мультиполифоническая MIDI-клавиатура которая позволяет сопоставлять жесты со звуковыми параметрами. Другая схожая интерпретация этой идеи это Хакен Континуум. Оба эти варианта поставляются с премиальным ценником, и по моему мнению - заслужено.

Следующий пример чуть мене комплексный. Genki Waves, насколько я понимаю, состоит в основном из кольца, которое может управлять программным обеспечением. Но сайт позволяет приобрести модуль eurorack и midi-адаптер 5din, что делает этот сетап вполне универсальным.

Другой вариант, если существует необходимость управлять железными синтезаторами Enhancia Neova ring. Полный комплект состоит из кольца, станции с современными 3,5 - мм MIDI входом и выходом и программного обеспечения для точной интерпретации жестов.

Но я не только не могу оправдать трату в 300 долларов на то, что могу сделать сам, я также хочу устройство, свободное от программного хоста в виде ПК, потому что я предпочитаю сетапы без управления с компьютера, и я хочу, чтобы все элементы контроля были рядом с реальным оборудованием.

Запустив быстрый гугл поиск я нашел библиотеку ESP32BLEMIDI, которая позволяет отправлять миди-сообщения посредством беспроводной блютуз связи, и которую люди, судя по информации, использовали успешно, и начал составлять план.

План состоит в использовании двух плат esp32. Один-как наручный сервер, собирающий данные с акселерометра и преобразующий их в сообщения об изменении высоты тона и модуляции. Я привяжу тангаж к бендам и крен к модуляции. Кроме того, поскольку на борту модуля MPU6050 есть встроенный гироскоп, для бендов я также буду собирать информацию о горизонтальном смещении, поскольку оно также отображает это интуитивное движение. Три потенциометра будут контролировать чувствительность каждой оси к соответствующему параметру. Литиевая батарея будет поддерживать беспроводную работу устройства с помощью модуля управления зарядкой. Этот конкретный модуль поддерживает все средства защиты и не имеет никаких ограничений по минимальному току, что, наконец, отправило платы на базе tp4056 для меня в отставку. В таком случае у меня будет возможность подключить свой компьютер к наручному блоку для управления программными синтезаторами с, я надеюсь, низкой задержкой. Для управления любыми железными блоками я также построю стационарный хаб, который сможет конвертировать беспроводные BLEMIDI сообщения в аппаратные MIDI сообщения для взаимодействия с аппаратными синтезаторами. Для этого хаба я выбрал контроллер с OLED-экраном и с помощью поворотного энкодера смогу переназначить бенды и модуляцию как любую другую MIDI CC команду для управления громкостью, панорамированием, позиции уэйвтейбла и всем тем, что конкретный синтезатор сможет изменить на лету. Я не могу собрать простую сквозную схему, она неизбежно повредит данные, это должна быть полноценная смешивающая схема. Я также добавлю 2 CV-выхода для взаимодействия с модульным и полумодульным оборудованием.

После пары вечеров пайки и еще нескольких дней программирования у меня на столе были прототипы. Наручный блок несколько громоздкий, но я уверен, что смогу уменьшить его размер по крайней мере в 3 раза. Я добавил включатель питания и кнопку начала/прекращения передачи данных под большой палец, и переключатель направления, чтобы переключаться между правой и левой рукой. Я также добавил аналоговый акселерометр, чтобы проверить, будет ли он работать с меньшей задержкой, чем цифровой.

Со стороны станции я припаял аппаратные MIDI входы и выходы и операционные усилители для усиления сигналов от ЦАПОВ до уровней CV, идущих на выходы 3,5 мм. Входящие BT-сообщения могут быть реорганизованы как любое MIDI СС-сообщение идущее через любой канал чтобы управлять несколькими синтезаторами одновременно, или переключаться между ними.

Первым делом стоит проверить работу напрямую с компьютером, для этого нужно выполнить сопряжение, выбрать режим драйвера в моей DAW-станции и установить флажок для прослушивания входящих сообщений. Данные с гироскопа создают много шума, все чувствуется слегка неконтролируемо, результаты намного чище когда на бенды влияют только данные с акселерометра. Тестирование показало, что существенной разницы между цифровым и аналоговым акселерометром нет.

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

После отключения всех остальных беспроводных соединений на моем компьютере, включая Wi-Fi, задержка сократилась, и проблема отключения стала менее частой. Это привело меня к выводу, что слабым звеном в этой цепочке являются беспроводные возможности моего компьютера. Поскольку мой конкретный аудиоинтерфейс не имеет MIDI-портов, я схватил Arduino Due и быстренько собрал USB-MIDI-интерфейс, чтобы иметь возможность сопряжать устройство со станцией, подключать станцию к интерфейсу миди-кабелем, подключать интерфейс к ПК и получать MIDI-сообщения таким образом. И проблема отваливания от блютуз исчезла.

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

Поскольку прямое BT подключение к моему компьютеру немного медленное, и я все равно скован использованием MIDI-USB интерфейса, вместо того чтобы читать значения, преобразовывать их в BT midi и отправлять медленные BT MIDI сообщения для отправки обычных MIDI, я решил полностью лишить сообщения универсального протокола и отправлять необработанные значения и преобразовывать их на принимающем конце в MIDI, уменьшая количество шагов и объем отправляемых данных. Для этого я использовал протокол ESPNOW, который без каких-либо махинаций с рукопожатиями при наличии только mac-адреса может отправлять только 3 байта данных на устройство, которое ожидает только 3 байта данных. Я удалил все куски кода с подтверждением передачи, чтобы уменьшить задержку. И все заработало безупречно.

Эта конкретная сборка работает нормально, на этом этапе стоит просто минитюаризовать дизайн и закончить печать всех корпусов. Но некоторые мелочи меня не устраивали.

Во-первых, это конструкция из 3 контроллеров, где на самом деле требуется только 2. Прием данных, создание MIDI и преобразование в USB MIDI должны происходить в одном устройстве. И это, как минимум в теории, довольно легко реализовать, потому что более поздняя версия ESP32 под названием S2 способна быть нативным USB устройством, что делает адаптацию кода довольно легкой. Но мало того, что этой штуки у меня нет, существуют и другие проблемы.

В основном энергопотребление. Текущая установка убивает относительно жирную батарейку через полчаса. Именно по этой причине на всех кадрах был шнур, это не связь, это просто для питания. И проблема даже не в емкости, а в возможностях токоотдачи этой батареи примерно на 3,5 В она просто перестает быть способной питать прожорливый BT/WIFI чип. Это заставляет меня поменять аппаратное обеспечение и перепроектировать все с нуля.

Поскольку лучшая прошивка с точки зрения задержки использовала прямую передачу пакетов, не будучи завернутой в очень специфический протокол, я решил использовать модули nrf24l01+, которые очень похожи в этом отношении. Это означает, что я могу соединить этот модуль с DUE, которая раньше был просто MIDI USB интерфейсом, и использовать его в качестве хаба, который и делает все - прием данных, аппаратное midi, USB midi, CV-напряжение, реорганизацию сообщений и т. Д.

В качестве передатчика у меня было 2 варианта Pro Micro и STM32 blue pill. Второй вариант не только менее энергозатратен, но и имеет гораздо большее разрешение на входах АЦП, что позволит избежать потенциальных резких рывков при изменении уровня эффекта. Не говоря уже о том, насколько большими вычислительными способностями он обладает.

Таким образом, сетап меняется от сложного чтения данных об ускорении, обертывания этих данных в протокол BLE MIDI, отправки BLE MIDI, преобразования в MIDI и преобразования из MIDI в USB MIDI к гораздо более простому чтения данных об ускорении, отправки этих необработанных данных, а затем простого преобразования их в USB MIDI. И как всем известно, простое решение это надежное решение.

Так что еще через пару вечеров у меня были очередные рабочие прототипы. Наручный блок намного меньше предыдущей итерации, тоньше и имеет гораздо более удобную кнопку. Я прикрепил ладовую заглушку, чтобы зафиксировать устройство на руке.

Я могу использовать встроенные в синтезатор бенды и модуляции. Я могу перенаправить разные CC на любой параметр VST на любом канале. Я могу использовать устройство для управления несколькими параметрами одного синтезатора. Я могу использовать устройство для управления параметрами нескольких VST одновременно. Можно во время или после записи прописать автоматизацию трека по параметру.

Так что в конце дня у меня было 3 версии одного и того же устройства. BT версия полезна в том случае, когда требуется только подключение к ПК. Будучи по своей сути BT сервером при переключении между ПК и хабом, я должен вручную прерывать соединение и каждый раз устанавливать новое. Поэтому, поскольку я не использую свой компьютер в качестве центра управления железными синтами (не то, чтобы мой аудиоинтерфейс это поддерживает) мне не хочется продолжать реализацию конкретно этой версии. Однако существует открытый проект умных часов, в которые встроен акселерометр. Сенсорный экран должен быть способен вместить в себя все меню, переключать каналы, номера CC сообщений и чувствительность и позволять хранить множество пресетов. Будучи проектом на базе ESP32, перенос проекта не должен вызвать много проблем, если когда-нибудь я заполучу его в свои руки. Я чувствую себя обязанным подчеркнуть, что я протестировал более одного модуля ESP32, и задержка колеблется от юзабельной до невыносимой, и я понятия не имею, как будет вести себя этот конкретный блок. Задержка также коррелировала с энергопотреблением более медленный модуль был способен жить от батареи гораздо дольше, разряжая ее должным образом.

То же самое устройство должно открыть возможность использовать версию на базе ESPNOW, которая показала наименьшую задержку, но я бы связал ее с ESP32-S2 в качестве хаба, чтобы иметь функционал нативного USB. В данный момент у меня нет ни того, ни другого, и я не собираюсь тратить на них деньги.

Тем более, что текущая рабочая версия, основанная на DUE и STM32, обеспечивает наилучший баланс между задержкой (она в принципе существует только в контексте версии ESPNOW) и простотой. Энергопотребление очень низкое и я не смог разрядить батарею во время тестирования. Станция поддерживает как USB, так и аппаратный MIDI одновременно, без необходимости ручного подключения, мне просто нужно щелкнуть переключатель и подать питание. Эту версию все еще можно сделать намного меньше, но в данный момент это не принципиально. Что можно поменять, так это железо. Либо поставить более мощную версию NRF24 в хаб, либо перенести весь проект на LORA.

Cсылка на видео (с демонстрацией игры)

Код

Инженерная цель данного эксперимента заключалась в разработке системы из трёх частей, а именно модели сегментации изображения, скрипта управления двигателем и спринклера, работающего под управлением Arduino. Эта система должна целенаправленно поливать участки травяного газона, что позволит сэкономить значительное количество воды, а заодно и времени.

Задача

Представьте, что вы прогуливаетесь по своему кварталу мимо красивых зелёных лужаек. Что такое?.. Вода же должна литься на газон, а не на тротуар рядом! Здесь люди ходят! Слева от вас большой газон орошается из-под земли десятком спринклеров. Но, хоть вся трава и поливается обильно, на газоне тут и там заметны проплешины. Многие не видят в этом проблемы эка невидаль! и безмятежно прыгают через лужи. Но проблема здесь не только в лужах, а в том, что, несмотря на использование такого количества воды, газон всё равно не растёт нормально. И проблема эта более серьёзная, чем можно подумать. В Америке от 30 до 60 % городской пресной воды используется для полива газонов, и самое печальное, что приблизительно 50 % этой воды тратится впустую из-за небрежно или неправильно установленной системы полива.

Уход за газонами недешёвое занятие. Чтобы газоны росли так, как нужно, необходимо правильно подобрать удобрения, компост и, самое главное, правильно их поливать. В этой статье я расскажу о разработанном мною решении какие шаги я предпринял при планировании, создании прототипа и внедрении.

Первоначальные соображения

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

Разница в цвете между светло-коричневыми участками и зеленью здоровой травы сразу бросается в глаза. Я начал решать задачу так: проанализировал RGB-значения различных областей изображения. Если бы я мог выявлять "менее зелёные" области и найти критерий, по которому такие участки можно было выделять, я мог бы их точно определить. Однако всё оказалось не так просто, как я думал.

Главной проблемой было множество внешних факторов, на которые я повлиять не мог, но они могли сами повлиять на результаты. Например, RGB-значение участка изображения может быть изменено ночным электрическим освещением. При таком количестве посторонних факторов система была бы просто нежизнеспособна. Мне определённо нужно было искать лучшее решение.

Сегментация изображений

Новое решение оформилось в виде концепции, называемой сегментацией изображения. Сегментация изображений это процесс машинного распознавания образов, разделяющий изображения на "сегменты" на основе сходства пикселей. В основном он используется, чтобы обнаруживать на изображении объекты (в таком случае он называется методом обнаружения объектов), и применяется в автономных транспортных средствах, при обработке медицинских изображений и спутниковой съёмке.

Используя метод сегментации изображений, я смог бы обнаружить проплешины на газоне. И я засел за изучение методов создания моделей сегментации изображений с помощью Tensorflow.

Я обнаружил замечательную библиотеку под названием ImageAI, написанную Олафенвой Мозесом. Библиотека ImageAI позволяет обнаруживать объекты с использованием набора данных, созданного пользователем. С помощью ImageAI мне удалось подобрать оптимальный набор данных, наиболее подходящий для моей модели.

Первый набор данных / Тестовый

Методы машинного обучения работают только в том случае, если в них заложены данные. Без большого количества точных и осмысленных данных обучать модели и получать прогнозы об окружающем нас мире практически невозможно. Если мы хотим хорошо обучить студента, мы должны предоставить ему как можно больше ресурсов, чтобы обучение было эффективным.

Бесплатные общедоступные наборы данных можно найти на множестве веб-сайтов и во многих приложениях. Эти данные, в частности, могут использовать инженеры при работе над проектами. Однако для моего проекта никаких наборов данных не было, и поэтому мне пришлось создавать свои собственные. Как выяснилось, создание набора данных оказалось чуть ли не самой сложной проблемой во всём проекте.

Набор данных для сегментации изображений состоит из двух частей: изображений и аннотаций. Существует множество способов аннотирования изображений, то есть пометок места расположения объекта на изображении. Я использовал формат Pascal VOC, сохраняющий аннотации в файлах .xml. То есть, если мой набор данных содержит 50 изображений, мне пришлось бы аннотировать каждое отдельное изображение и создать 50 xml-файлов с аннотациями соответствующих изображений.

Вначале у меня было много вопросов о наборе данных: сколько изображений нужно иметь, как аннотировать изображение, как использовать аннотацию в коде, как узнать, подходит ли для модели то или иное изображение, и так далее. Тут мне здорово помог Олафенва Мозес, который, к счастью, написал очень информативную статью о том, как создавать пользовательский набор данных и использовать его в библиотеке ImageAI.

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

После сбора изображений я закомментировал их с помощью программы Label IMG. Я создал каталог с изображениями и каталог для аннотаций. Затем я поставил аннотацию к каждому изображению, обведя в рамки все проплешины. Привожу ниже скриншот программы Label IMG, которую я использовал для аннотирования изображений.

Я, наконец, получил полный набор данных с аннотациями и изображениями и был готов приступить к обучению своей модели. С набором данных и загруженными библиотеками у меня возникло много проблем, но мне удалось их решить, и я обучил свою первую модель за 15 эпох с размером пакета 4.

После тестирования модели на изображении моей лужайки перед домом у меня получился вот такой результат. Я так долго не мог добиться, чтобы программа хотя бы доходила до конца без ошибок, что был в восторге даже от того, что она, наконец, обвела проплешину рамкой! То, что полученный результат был ужасен и абсолютно бесполезен для работы системы, я понял уже позднее. Модель, в принципе, способна обозначать область с плохой травой. Однако получившиеся границы очень неточны, и такой результат практически бесполезен.

Наборы данных 24 / Последующие тесты

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

Полистав Интернет, я обнаружил такую вещь, как парсеры (web scrapers). Парсер это инструмент, способный извлекать данные и содержимое с веб-сайтов и загружать эти файлы на локальный компьютер. Это было как раз то, что мне нужно, и после изучения краткого руководства я создал элементарный парсер, загружающий изображения, содержащие ключевые слова "трава с проплешинами", "плохая трава" и "плохой газон". С помощью этого парсера я собрал папку из 180 изображений, и это был мой второй набор данных.

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

Я обратился кое к кому за помощью, поизучал ещё теорию и вычитал, что есть такой хитрый приём аугментация изображений (image augmentation), то есть процесс, с помощью которого набор данных может быть расширен посредством внесения изменений в существующие изображения. Количество изображений меняется за счёт того, что меняются их ориентация и RGB-значения пикселей. Пример аугментации изображений.

Для нас, людей, все приведённые выше изображения одинаковы, если не считать крохотных изменений; однако для компьютера, который рассматривает изображения как массивы значений пикселей, эти изображения совершенно разные. Попробуем использовать эту идею и создадим больше обучающих данных. И вот, я, страдавший от нехватки изображений, сразу получил их много больше, чем значительно улучшил свой набор данных. Для пополнения всего каталога изображений я использовал библиотеку Keras с определёнными параметрами и граничными значениями. Мой четвёртый набор данных содержал 300 изображений. Теперь я был уверен, что модель, наконец, заработает. Но неожиданно возникла ещё одна серьёзная проблема.

Проблема совместимости библиотек

В большинстве проектов по программированию, особенно проектов в области анализа и обработки данных, для работы определённых функций и инструментов требуется ряд библиотек и зависимостей. В этом конкретном проекте библиотека ImageAI потребовала установки определённых версий различных библиотек, в том числе tensorflow-gpu 1.13 и keras 2.4.

Разные версии библиотеки отличаются одна от другой, причём использование разных версий может повлиять на взаимодействие между библиотеками. В моём случае это было особенно актуально, так как обучение и работа модели были возможны только при использовании определённых версий библиотек.

В январе вышло обновление библиотеки ImageAI, и оно сразу поставило крест на работе других библиотек, которые я использовал в проекте, оно было просто несовместимо с ними. И вот, время обучения, обычно составлявшее около 5 минут на эпоху, стало составлять более 14 часов. Кроме того, модель постоянно перестраивалась под данные, а это свидетельствовало о том, что она была неспособна генерализовывать новые данные.

Сначала я подумал, что такое длительное время обучения обусловлено большим количеством изображений в наборе данных, но скоро стало очевидно, что проблема кроется не в этом и она более серьёзная. Я ещё раз обратился к учебникам, но ничего путного найти не смог. Если бы вы знали, сколько различных вариантов я перепробовал, чтобы устранить проблему!.. Я пробовал менять способы извлечения набора данных, менять аппаратный ускоритель, менять размер пакета... Ни один из этих вариантов не снизил время обучения модели.

Но тут я наткнулся на недавно опубликованный пост в разделе проблем и вопросов на Github, в котором кто-то жаловался на такую же точно проблему, как и у меня. Олафенва Мозес, создатель библиотеки, ответил на это пост и объяснил проблему, предложив собственное решение. Суть этого решения была такой: три основные библиотеки Tensorflow, Keras и ImageAI должны иметь чётко определённые версии.

Окончательный набор данных / Модель

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

Я решил добавить ещё больше данных и в итоге получил набор из 1738 изображений. Чтобы обучить модель, мне пришлось аннотировать каждое изображение, вручную очерчивая участки на каждом из них. К счастью, этой работой я занимался не один, а с друзьями. Менее чем за два часа нам удалось аннотировать все изображения.

Окончательный набор данных был разделён на 1400 тренировочных и 338 тестовых изображений. После обучения модели за 5 эпох я провел валидацию и получил впечатляющий результат 0,7204, что, безусловно, стало моим лучшим результатом с начала проекта.

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

Создание спринклера

Чтобы контролировать полив, мне нужно было обеспечить вращение спринклера по двум осям так я мог бы контролировать расстояние и направление разбрызгивания воды. Я использовал два шаговых двигателя NEMA с разными характеристиками мощности и крутящего момента. Нижний двигатель NEMA-23 использовался для управления направлением разбрызгивания воды. Верхний двигатель NEMA 14 вращал стержень с закреплённым на нём с помощью трубки из ПВХ спринклером, чтобы можно было управлять расстоянием, на которое разбрызгивается вода. Для управления этими двигателями я использовал Arduino, два регулятора частоты вращения двигателя A4988 и два адаптера питания 12 В.

Если бы я мог выяснить, на какое расстояние разбрызгивается вода и на какой угол поворачивается спринклер за определённое количество шагов, я мог бы рассчитать коэффициенты преобразования шагов в углы и шагов в расстояние. Для того чтобы можно было использовать такие коэффициенты преобразования, мне потребовался скрипт, определяющий фактическое расстояние до проплешины и угол, на который надо повернуть спринклер для полива.

Я рассчитал угол, на который необходимо повернуть спринклер от начального места до центра проплешины, определил приблизительное количество пикселей/футов на моём изображении и после этого вычислил приблизительное расстояние до центра проплешины.

На рисунке выше показаны результаты работы скрипта управления двигателем. Их них следует, что спринклер должен повернуться на 42, а расстояние до проплешины составляет примерно 3 м 89 см.

Длина рулетки 3 м (10 футов); от центра проплешины до спринклера примерно 12 футов 9 дюймов (3,8862 м), как и предсказал скрипт.

Я выполнил несколько тестов для определения коэффициентов преобразования шагов в углы и шагов в футы, и это позволило мне создать скрипт Arduino для ориентирования спринклера на проплешину с использованием данных скрипта управления двигателем.

Готовность к окончательному тестированию

К сожалению, всю систему в итоге мне протестировать не удалось.

Перед окончательным тестом я стал проверять готовую конструкцию, чтобы убедиться, что она способна держать спринклер и поворачивать его. Но я был очень неосторожен: в моторы попала вода, и они сгорели. Двигатели были довольно дорогими, а покупать новые было непрактично.

Анализ кода / Краткий обзор

Google Colab PatchDetector

PatchDetector на Github

!wget https://github.com/fazalmittu/PatchDetection/raw/master/BlackedOutLawn.jpg!wget https://github.com/fazalmittu/PatchDetection/raw/master/BlackedOutLawn_Detected.jpg!wget https://github.com/fazalmittu/PatchDetection/releases/download/v3.0/detection_model-ex-04--loss-25.86.h5!wget https://github.com/fazalmittu/PatchDetection/releases/download/v3.0/detection_config1700_v1.json!wget https://github.com/fazalmittu/PatchDetection/raw/master/BlackedOutFullLawn.jpg!wget https://github.com/fazalmittu/PatchDetection/raw/master/BlackedOutFullLawn_Detected.jpg!wget https://github.com/fazalmittu/PatchDetection/raw/master/SprinklerPOV.jpg!wget https://github.com/fazalmittu/PatchDetection/raw/master/SprinklerPOV_Detected.jpg!wget https://github.com/OlafenwaMoses/ImageAI/releases/download/essential-v4/pretrained-yolov3.h5

Этот код используется для импорта модели и изображений (для тестирования), которые я хранил на Github, чтобы их можно было легко извлечь с помощью Google Colab. Последняя строка импортирование предварительно обученной модели YOLO-v3, которая, в свою очередь, использовалась для обучения модели (трансферное обучение).

!pip uninstall -y tensorflow!pip install tensorflow-gpu==1.13.1!pip install keras==2.2.4!pip install imageai==2.1.0!pip install numpy

Этот код импортирует определённые версии библиотек, необходимых при проектировании. Используемые библиотеки: tensorflow-gpu, keras, imageai и numpy.

%load_ext autoreload%autoreload 2  from google.colab import driveimport sysfrom pathlib import Pathdrive.mount("/content/drive", force_remount=True)base = Path('/content/drive/MyDrive/PatchDetectorProject/')sys.path.append(str(base))zip_path = base/'AugmentedDataSetFinal.zip'!cp "{zip_path}" .!unzip -q AugmentedDataSetFinal.zip!rm AugmentedDataSetFinal.zip

Этот код используется для получения набора данных из места, которое я определил для него на Google-диске. Для сохранения на Github набор данных был слишком велик, поэтому мне пришлось использовать альтернативный источник.

from imageai.Detection.Custom import DetectionModelTrainerfrom __future__ import print_functiontrainer = DetectionModelTrainer()trainer.setModelTypeAsYOLOv3()trainer.setDataDirectory(data_directory="AugmentedDataSetFinal")trainer.setTrainConfig(object_names_array=["patch"], batch_size=4, num_experiments=5, train_from_pretrained_model="pretrained-yolov3.h5")trainer.trainModel()

В этом коде осуществляется обучение модели. В нём указывается объект для поиска ("patch" (проплешина)), количество эпох (5), размер пакета (4) и используется трансферное обучение.

from imageai.Detection.Custom import DetectionModelTrainertrainer = DetectionModelTrainer()trainer.setModelTypeAsYOLOv3()trainer.setDataDirectory(data_directory="AugmentedDataSetFinal")trainer.evaluateModel(model_path="AugmentedDataSetFinal/models", json_path="AugmentedDataSetFinal/json/detection_config.json", iou_threshold=0.5, object_threshold=0.3, nms_threshold=0.5)

Этот код используется для валидации модели. С окончательной моделью я получил оценку 72,04 %. Я считаю этот результат очень хорошим, учитывая, что обнаруживаемые мною объекты представляют собой проплешины без определённой формы, цвета или размера.

from imageai.Detection.Custom import CustomObjectDetectionfrom PIL import Image, ImageDrawimport numpy as npdetector = CustomObjectDetection()detector.setModelTypeAsYOLOv3()detector.setModelPath("/content/detection_model-ex-04--loss-25.86.h5")detector.setJsonPath("/content/detection_config1700_v1.json")detector.loadModel()detections = detector.detectObjectsFromImage(input_image="SprinklerPOV.jpg", output_image_path="SprinklerPOV_Detected.jpg", minimum_percentage_probability=30) i = 0coord_array = []for detection in detections:    coord_array.append(detection["box_points"])    print(detection["name"], " : ", detection["percentage_probability"], " : ", detection["box_points"])    i+=1print(coord_array)detected = Image.open("SprinklerPOV_Detected.jpg")box = ImageDraw.Draw(detected)for i in range(len(coord_array)):  box.rectangle(coord_array[i], width=10)detected

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

!wget https://github.com/fazalmittu/PatchDetection/raw/master/FeetToPixel.JPGimg_ft = Image.open("FeetToPixel.JPG")ft_line = ImageDraw.Draw(img_ft)ft_line.line([(175, 1351), (362, 1360)], fill=(0, 255, 0), width=10)ft_distance = np.sqrt(9*9 + 187*187)print(ft_distance)img_ft

С этого кода начинается скрипт управления двигателем. Код импортирует изображение, на нём разложенная на траве рулетка. Я использовал это изображение для определения примерного количества пикселей в футе.

from PIL import Image, ImageDraw#TOP LEFT = [0, 1]#BOTTOM LEFT = [0, 3]#TOP RIGHT = [2, 1]#BOTTOM RIGHT = [2, 3]img = Image.open("SprinklerPOV_Detected.jpg")middle_line = ImageDraw.Draw(img)avg_1Line = ImageDraw.Draw(img)avg_2Line = ImageDraw.Draw(img)avg_1 = (coord_array[1][1] + coord_array[1][3])/2avg_2 = (coord_array[1][0] + coord_array[1][2])/2middle_line.line([(2180, 0), (2180, 3024)], fill=(0, 255, 0), width=10)# avg_1Line.line([(coord_array[1][0], coord_array[1][1]), (coord_array[1][0], coord_array[1][3])], fill=(255, 0, 0), width=10)# avg_2Line.line([(coord_array[1][0], coord_array[1][3]), (coord_array[1][2], coord_array[1][3])], fill=(255, 0, 0), width=10)def find_angle():  line_to_patch = ImageDraw.Draw(img)  line_to_patch.line([(avg_2, avg_1), (2180, 3024)], fill=(255, 0, 0), width=10)  length_1_vertical = 3024 - avg_1  length_2_horizontal = 2500 - avg_2  print("Distance = ", np.sqrt(length_1_vertical*length_1_vertical + length_2_horizontal*length_2_horizontal)/ft_distance, "ft")  angle_radians = np.arctan(length_2_horizontal/length_1_vertical)  angle = (180/(np.pi/angle_radians)) #Convert radians to degrees  return angleprint(avg_1, avg_2)print(find_angle())img

Этот код используется для определения угла до проплешины. Я нарисовал треугольник от центра проплешины до места, где вначале находился спринклер. Для определения угла до центра проплешины я воспользовался тригонометрическими формулами и координатами каждой из точек. Для определения расстояния до центра проплешины в футах я также использовал тригонометрические функции и коэффициент пересчёта пикселей в футы.

/* *  * Fazal Mittu; Sprinkler Control *  */const int ROTATEstepPin = 3; const int ROTATEdirPin = 4; const int ANGLEstepPin = 6;const int ANGLEdirPin = 7;const int ROTATEangle = 42.25191181;//TODO: Find Conversion: Steps --> Angle 1000 steps = 90 degreesconst int ANGLEangle = 12.76187539;// pixels --> ft: 187 pixels = 1 feetbool TURN = true;float angleToSteps(float angle){  float steps = 1000/(90/angle);  return steps;}float ftToSteps(float feet) {  float steps = 100/(8/feet);  return steps;}void setup() {  Serial.begin(9600);  pinMode(ROTATEstepPin,OUTPUT);   pinMode(ROTATEdirPin,OUTPUT);  pinMode(ANGLEstepPin,OUTPUT);   pinMode(ANGLEdirPin,OUTPUT);}void loop() {  int ROTATEsteps = angleToSteps(ROTATEangle); //Angle was determined using Python Script  int ANGLEsteps = angleToSteps(ANGLEangle);  delay(7000);  if (TURN == true) {    for(int x = 0; x < ROTATEsteps; x++) {      digitalWrite(ROTATEstepPin,HIGH);       delayMicroseconds(500);       digitalWrite(ROTATEstepPin,LOW);       delayMicroseconds(500);     }    delay(5000);    for (int x = 0; x < 100; x++) { //100 steps = 8 ft, 0 steps = 14.5 ft      digitalWrite(ANGLEstepPin,HIGH);       delayMicroseconds(500);       digitalWrite(ANGLEstepPin,LOW);       delayMicroseconds(500);    }  }  TURN = false;}

Приведённый выше код использовался для управления обоими двигателями. Перед использованием любого кода сначала нужно определить взаимозависимости шаги/градусы и шаги/футы, что я и сделал посредством проведения тестов и измерений. В итоге у меня появился рабочий скрипт, который мог управлять работой двигателей в соответствии со значениями, полученными в результате работы скрипта управления.

Заключение

Даже несмотря на печальную судьбу двух двигателей, работа над этим проектом доставила мне истинное удовольствие. Я узнал, как собирать данные, как увеличивать количество изображений, как строить модели. Я понял, как интерпретировать результаты, как создавать систему управления, как подключать механические части, а также научился разгребать подводные камни на пути к успеху.

А если вы хотите научиться работать с данными и обрабатывать их помощью машинного обучения обратите внимание на наш курс по ML или на его расширенную версию Machine Learning и Deep Learning, партнером которого является компания Nvidia.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

В предыдущей статье, посвящённой моим попыткам погрузится в увлекательный мир программирования микроконтроллеров, я грозился сделать обзор на "обновку". К сожалению, мне сейчас не хватает навыков и времени чтобы сделать, что-то достойное полноценного обзора. Однако, я всё-таки решил подготовить забавы ради, короткую статью на тему игрушечного соревнования CANNY 3 TINY PRO и неоригинальной Arduino Nano. Соревноваться контроллеры будут в своеобразном аналоге перетягивания каната, на роль которого был выбран двухцветный светодиод марки BL-L2519EGW.

Итак в сегодняшнем материале мы подключим оба контроллера к светодиоду и будем подавать случайный сигнал на его выводы. Правила простые кто большее напряжение подаст у того и кристалл в светодиоде загорится ярче. Попутно мы воспользуемся ЦАП на контроллере CANNY и доработаем стандартный ГСЧ с помощью составного функционального блока.

В статье не будет сложной электроники или мудрёного программирования, так что она вполне подойдет новичкам.

Оглавление:

1. Введение

2. Схема

3. Программа

4. Заключение

Введение

Я намерено не буду разбирать технические характеристики нового (для меня) контроллера CANNY. Скажу только одну вещь. Несмотря на то, что они оба контроллера внешне чем-то похожи сравнивать их совершенно не уместно и мы этого делать не будем.

Для того, чтобы повторить "дуэль века" вам потребуется:

1. Двухцветный светодиод - я использовал BL-L2519EGW, но марка не особо критична.

2. Контроллер CANNY 3 TINY PRO именно у этого контроллера есть ЦАП, к тому же он самый доступный по цене в линейке контроллеров CANNY.

3. Совместимый с Arduino контроллер - я использовал неоригинальную Nano, но можно было и UNO.

4. Пара резисторов 100 Ом, - я не силен в электронике, но решил подстраховаться и использовать их как ограничители тока (может это и неверное решение). В любом случае думаю, что у контроллеров есть свои встроенные ограничители тока и схема может работать и без резисторов.

5. Соединительные провода и макетная плата.

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

Предвосхищая некоторую критику, сразу скажу, что само собой раз контролеры Кэнни стоят в "Дакаровских" Камазах, наверное и CANNY 3 TINY PRO явно предназначен для чего-то большего, чем просто моргать светодиодом. Собственно Arduino Nano тоже может намного больше. Просто я ничего сложнее в этот раз собрать не смог, а поделится впечатлением хотелось.

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

Схема

Питать контроллеры мы будем через USB-порты, поскольку оба контроллера имеют USB-VCP мы при необходимости сможем еще и передавать данные. Но в принципе контроллеры можно питать и от двух USB зарядных устройств, схема всё равно будет работать.

Первым делом объединим "Землю" у двух контроллеров соединив выводы "GND".

Затем, от каждого из контроллеров "подведем" к светодиоду выводы от канала ЦАП.
У Arduino - "D5", у CANNY - "C2" (это единственный выход с ЦАП).
В нашем случае светодиод имеет два вывода и работает он примерно так: если на левой ноге напряжение больше, чем на правой то загорается красный кристалл. Чем больше разница потенциалов, тем ярче он загорится. И наоборот, если на правой ноге напряжение больше, чем на левой, то загорится зеленый. При примерном равенстве потенциалов светодиод вообще не будет светится.

Мы будем "перетягивать канат" 2.5 секунды, нам важно, чтобы контроллеры подали сигнал более-менее синхронно. Для этого (а также для нашей тренировки) контроллеры подадут друг другу сигналы. Выход "D7" Arduino подаст логическую единицу на вход "C6" CANNY. В свою очередь, CANNY с выхода "C4" подаст логическую единицу на вход "D3" Arduino. В программе каждого из контроллеров предусмотрим проверку наличия сигнала, при успешном прохождении которой подается напряжение на светодиод.

Для того, чтобы узнать какое напряжение подали оба контроллера, мы с помощью АЦП CANNY померим напряжение поданное Arduino. Для этого подсоединим выход "C10" CANNY к резистору.

Кстати лично я очень рад что у Canny 3 TINY PRO для того, чтобы включить режим АЦП канала не нужно паять перемычку, как в случае с обычным CANNY 3 TINY.

В итоге должно получится примерно вот-так:

Я правда использовал специальные резисторы из набора, но в остальном схема как на картинке.

Ещё важно напомнить, что у кристаллов внутри светодиода немного разные электрические параметры, поэтому возможно, что будут светится одновременно оба кристалла, также возможны другие непредвиденные мелочи, которыми мы можем пренебречь.

Перейдем к программной части.

Программа

Обе программы можно скачать с GitHub.

Программа для Arduino очень простая, думаю нет смысле её комментировать:

/*Synhronized Randomize DAC.See more http://personeltest.ru/aways/habr.com/ru/post/561148/*/int ADC_pin = 5;int input_pin = 3;int output_pin = 7;int synch_signa = 0;int v_min = 10;int v_max = 2550;int synch_signal = 0;float rand_voltage = 0;// the setup function runs once when you press reset or power the boardvoid setup() {  pinMode(ADC_pin, OUTPUT);  pinMode(output_pin, OUTPUT);  digitalWrite(output_pin,HIGH);  pinMode(input_pin, INPUT);  Serial.begin(9600);}// the loop function runs over and over again forevervoid loop() {synch_signal = digitalRead(input_pin);      // read signal from another deviceif (synch_signal) { rand_voltage=random(v_min, v_max) / 10; analogWrite(ADC_pin, rand_voltage); Serial.println(rand_voltage);  delay(2500);   // wait for seconds}else{ delay(500);   // wait for seconds}                }

Программа для контроллера CANNY:

• При включении контроллер устанавливает на выходе "С4" логическую "1" для синхронизации с Arduino.

• Канал "C10" в режиме АЦП измеряет напряжение от Arduinio и с помощью функции MAP переводит его в удобный для чтения вид.

• ШИМ-генератор в сочетании с детектором переднего фронта раз в 2.5 секунды дают сигнал для записи случайного значения в канал "C2".

  • Значение при этом запишется, только если на входе "С6" есть логическая "1" от Arduino.

  • Значение напряжения для подачи на светодиод генерируется случайным образом. Поскольку у CANNY нет встроенного блока для сброса ГСЦ, "случайность" сигнала обеспечивается, сложением "истории" сигналов, поступивших от Arduino.

  • Для уменьшения количества элементов на основной диаграмме, реализация функции "Random" перенесена в одноименный составной блок (об этом чуть позже).

• Значения напряжений на выводах светодиода от обоих контроллеров передается в виртуальный COM-порт ПК. Данный порт мы можем мониторить в любой программе, например в Hterm, но я для простоты решил использовать Arduino IDE.

  • Чтобы не "заморачиваться" с лишними символами, напряжение контроллеров выводится без точки, например, "c=45" значит, что напряжение на выводе ЦАП CANNY = 4.5В, соответственно "a=27" значит, что на ЦАП выводе Arduino = 2.7В.

Рассмотрим составной блок "Random (min...max)":

В данном блоге мы используем встроенный ГСЧ и функцию MAP для того чтобы выводить не просто числа от 0 до 65000, а в нужном нам диапазоне. Данный блок можно использовать, как библиотечный элемент и повторно использовать в других схемах. Более подробно о том, как работать с составными функциональными блоками, я писал в этой статье.

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

Заключение

Если вы все собрали верно, то получится примерно такой результат:

Слева направо:

1. У контроллеров ничья, напряжение примерно равно.

2. CANNY немножко выигрывает.

3. CANNY ощутимо выигрывает.

4. Arduino ощутимо выигрывает.

Пример вывода данных из монитора COM-порта (несвязанный с картинкой выше):

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

Ну и еще под конец хочу сказать, что чертовски любопытно иногда погрузится в другую парадигму программирования. Я получил удовольствие, когда своими руками из функциональных блоков собрал простенький аналог функции "Random". Сейчас подумываю сделать еще несколько "библиотечных" элементов реализующих распространенные функции, которых порой не хватает среди готовых блоков CANNY и набросать об этом статью.

На этом всё. Надеюсь, что статья была для вас если уж не особо полезна, то хотя бы просто любопытна.

Автор: Alex Wulff (из-за глюков хабраредактора не получилось оформить как перевод)

К старту курса о разработке на С++ мы перевели статью о персональном регистраторе молний небольшом устройстве, сообщающем об ударах молнии поблизости. Оно даже сообщает, на каком расстоянии ударила молния; при этом, по словам автора, собрать его самому обойдётся дешевле, чем купить в магазине. Ещё один очевидный плюс вы сможете отточить свои умения в схемотехнике.

В основу устройства положен детектор молний AS3935 с ВЧ-каналом производства DFRobot. Детектор обнаруживает электромагнитное излучение молнии и с помощью специального алгоритма преобразовывает эту информацию в информацию о расстоянии до удара.

Датчик может обнаруживать удары молнии на расстоянии до 40 км (25 миль) и определять расстояние до места удара молнии с точностью до 4 км (2,5 мили). Сам датчик довольно надёжен, но может срабатывать неверно, если устройство находится на открытом воздухе. Самодельное устройство может работать не так надёжно, как коммерческий регистратор молний.

1. Разработка схемы соединений

Схема устройства проста. Информация с датчика молнии передаётся по линиям SCL и SDA, плюс к этому одно соединение предусмотрено для звукового сигнала. Устройство питается от литий-ионного полимерного аккумулятора (LiPo), поэтому я решил встроить в схему зарядное устройство для такой батареи.

Схема устройства показана на рисунке A. Обратите внимание, что аккумуляторная батарея LiPo соединяется с зарядным устройством через штекерно-гнездовые разъёмы JST и не требует пайки.

2. Сборка схемы

Для сборки устройства лучше всего применить так называемую технику свободной сборки. Детали не крепятся к подложке (например к перфорированной плате) а просто соединяются проводами (рис. Б). Так устройство собирается гораздо быстрее и получается меньше по размеру. Правда, страдает эстетика... Но сомнительную эстетику никто не увидит, если сборку закрыть напечатанным на 3D-принтере корпусом. На видео выше показано, как я собрал схему методом свободной сборки.

Подсоедините жучок к зарядному устройству

Отпаяйте зелёные клеммы от зарядного устройства LiPo. Они бесполезны, но занимают пространство. Соедините положительную (+) и отрицательную (-) клеммы зарядного устройства аккумуляторной батареи LiPo с положительной (+) и отрицательной () клеммами на лицевой части жучка. По этим проводам первичное напряжение батареи LiPo будет подаваться непосредственно на микроконтроллер. Технически жучку требуется 5В, но от напряжения 4В батареи LiPo он всё равно будет работать.

Подключение датчика молнии

Обрежьте входящий в комплект четырёхконтактный кабель так, чтобы от провода осталось примерно 5 см. Зачистите концы и подключите кабель к датчику молнии, выполнив следующие соединения:

• положительную (+) клемму на датчике молнии соедините с положительной (+) клеммой на жучке;

• отрицательную () клемму на датчике молнии соедините с отрицательной (-) клеммой на жучке;

• контакт синхронизации (C) на датчике молнии соедините с колодкой SCL на жучке;

• контакт данных (D) на датчике молнии соедините с колодкой SDA на жучке.

Контакт IRQ на датчике молнии также должен быть соединён с колодкой RX на жучке. Соединение должно подходить к аппаратному прерывателю на жучке; колодка RX (контакт 0) единственный оставшийся контакт, поддерживающий прерывание.

Подключение зуммера

Подключите короткий провод зуммера к отрицательной () клемме на жучке (земля), а длинный провод к контакту 11. Сигнальный вывод зуммера должен быть подключён к выводу PWM (для обеспечения максимальной гибкости), здесь идеально подходит контакт 11.

Подсоединение переключателя

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

Обрежьте красный провод на аккумуляторной батарее примерно наполовину и к каждому концу припаяйте провода от выключателя. Эти соединения показаны с правой стороны на рисунке Б. Обязательно закройте открытые участки провода термоусадочной трубкой или залейте горячим клеем, так как они могут соприкоснуться с одним из заземляющих проводов и привести к короткому замыканию. После подсоединения переключателя к зарядному устройству можно подключить аккумулятор.

Окончательная компоновка

Последний шаг избавляемся от беспорядочного скопления проводов и компонентов и приводим устройство в более презентабельный вид (рис. В). Это нужно делать аккуратно, чтобы не переломить провода. Приклейте горячим клеем зарядное устройство LiPo к верхней части батареи LiPo, затем сверху приклейте жучок. И последнее действие: приклейте к самому верху датчик молнии. Зуммер я вывел на сторону, как показано на рисунке В. В результате получилось несколько скреплённых между собой плат с торчащими из них проводами. Выводы переключателя я также оставил свободными, чтобы позже вставить их в корпус, распечатанный на 3D-принтере.

3. Программирование микроконтроллера

Запустите на компьютере Arduino IDE и убедитесь, что в меню ToolsBoard (ИнструментыПлата) выбрано значение Leonardo. Загрузите и установите библиотеку для датчика молнии. Затем скачайте код проекта и загрузите его на жучок. Программа предельно проста и очень легко настраивается.

Обнаружив молнию, устройство сначала подаст несколько звуковых сигналов, чтобы предупредить об ударе молнии поблизости, а затем подаст определённое количество звуковых сигналов, соответствующее расстоянию до молнии в километрах. Если молния находится на расстоянии менее 10 км (6,2 мили), детектор подаст один длинный звуковой сигнал. Если расстояние превышает 10 км (6,2 мили), расстояние будет поделено на 10, округлено, и устройство подаст соответствующее полученному числу количество сигналов. Например, если молния ударит на расстоянии 26 км (16 миль), то сигнала будет три.

Программное обеспечение запускается прерываниями от датчика молнии. Когда он обнаружит электромагнитное излучение от удара, на контакт IRQ подаётся высокое напряжение, оно вызывает прерывание в микроконтроллере. Датчик также может посылать прерывания для событий, не связанных с ударом молнии, например при превышении порогового уровня помех/шума.

В этом случае нужно отойти с детектором подальше от электронных устройств. Исходящее от таких устройств излучение может "забить" сравнительно слабое излучение удалённого удара молнии.

4. Распечатка корпуса на 3D-принтере (не обязательно)

Корпус для устройства разработал я сам. Файлы для 3D-печати можно загрузить здесь. (рис. Г, Д). Верхняя часть корпуса прищёлкивается к нижней, никакого специального оборудования не требуется. Корпус достаточно просторный, чтобы в нём могло поместиться и ваше устройство, если вы будете собирать его по-другому (рис. Д). В любом случае вам ничего не мешает спроектировать аналогичный корпус самому:

• определите габариты устройства;

• спроектируйте устройство в программе CAD (мне нравится Fusion 360 студенты могут получить её бесплатно);

• создайте корпус, перетащив профиль из модели устройства. Допуска в 2 мм будет вполне достаточно.

Обнаружение ударов молнии

Поздравляем, теперь у вас есть работающий регистратор молний! Как проверить, работает ли устройство? Ответ очевиден дождитесь грозы. Не знаю, насколько надёжен датчик, но мой сработал с первого раза.

Заряжать устройство очень просто достаточно подключить microUSB-кабель к зарядному устройству LiPo и дождаться, когда индикатор зарядки загорится зелёным цветом. Во время зарядки устройство должно быть включено, иначе энергия не будет поступать в аккумулятор!

Внесение изменений

Регистратор молнии можно сделать более полезным и удобным в использовании, если внести в программное обеспечение определённые изменения:

• другие звуковые сигналы: чтобы устройство звучало приятнее, используйте библиотеку звуков Tone.h;

• спящий режим: микроконтроллер ATmega32u4 (чип, на основе которого работает жучок) поддерживает аппаратные прерывания в спящем режиме. Устройство можно перевести в спящий режим, и любое поступившее от датчика молнии, событие заставит датчик реагировать. Спящий режим может значительно продлить срок службы батареи.

Этот материал показывает, что умение разрабатывать программы на С++, работа с электроникой, даёт широкие возможности и может быть полезна в самых разных сферах: представьте, например, что вы часто бываете на природе тогда о грозе лучше знать заранее и даже за километры, но не нужно дорогого оборудования. Если вам нравится чувствовать, как вы управляете железом, идущим по микросхемам током, то вы можете присмотреться к нашему курсу о разработке на С++, где студенты готовятся к началу карьеры разработчика ПО на этом сложном и мощном языке.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Электронное устройство, которое применяется в декоративных инсталляциях. Светодиодные кубы бываю размерами 3x3x3, 4x4x4, 5x5x5 и т.д. Изменяя скорость загорания и затухания светодиодов в кубе, мы создаём различные визуальные эффекты: бегущие огни, эквалайзер, 3d световая инсталляция.

Материал:

- плата для пайки или беспаечная плата

Инструменты:

- инструмент для снятия изоляции

- линейка или штангельциркуль

- паяльная станция

Электрокомпоненты

- arduino

- 64 светодиода

- соединительные провода

Рассмотрим схему данного куба

На рис. Представлена одна из сторон куба. Все четыре стороны соединяются по выводам плюсовой ножки светодиода в каждом ряду. В результате для всех ножек с полюсом + ,будет четыре вывода. В результате с помощью этих выводом можно управлять рядами светодиодов. Ножки с полюсом - соединяются между собой по вертикальным рядам куба. В результате мы получим 16 выводов, которые можно запитать на GND arduino.

Сборка модели.

Соберём конструкцию с использованием паяльной станции и платы для монтажа. Можно воспользоваться как платой для пайки, так и без пайки. Плату для пайки, рекомендую использовать только, если вы уверены в правильности сборки

Для того чтобы светодиоды образовали куб, их необходимо спаять друг с другом согласно схеме на рис. С помощью данной схемы мы получим одну из сторон куба.

Для начала, соберём вертикальный ряд из четырёх светодиод. У короткой ножки светодиода (знак - ) подогнём конец с помощью плоскогубец. Длинную ножку светодиода сдвинем перпендикулярно короткой.

Используя держатель Третья рука, спаяем данные светодиоды

Как видно из рисунка, короткие ножки мы спаяли, а длинные ножки остались свободными. Так необходимо проделать ещё четыре раза. В итоге, мы получим четыре ряда светодиодов

Приступим к процессу их соединения. Соединяться они должны с помощью длинных ножек (знак + ). Соединение получается с помощью перекрестия. Постарайтесь уместить на одной длинной ножке светодиода четыре другие длинные ножки светодиодов

Так необходимо проделать для трёх сторон. С каждой стороны должно быть не больше четырёх вертикальных рядов.

Перед тем как поставить четвёртую стену куба, необходимо припаять четыре провода к плюсовым выводам светодиодов каждого ряда.

После этого, припаяем четвёртую сторону куба.

Для того чтобы куб был устойчив нужно закрепить его ножки минуса на монтажной плате, как предназначенный для пайки, так без пайки. В данном случае для надёжности конструкции я применил плату для пайки.

Минусы подключим к GND, а плюсы к пинам 8, 9, 10, 11 arduino. И напишем простую программу.которая поочередно посылает сигналы на ряды данного куба.

Процесс управления, а точнее, усложнения управления, можно воспользоваться сдвиговым регистром 74HС595. Данная микросхема способна управлять восемью светодиодами, т.е. может посылать сигналы на восемь выводов и при этом сама занимает три вывода на arduino. Если все шестнадцать выводов GND светодиодов подключить к двум регистрам, совместно с питанием плюсовых выводом, то можно регулировать свечение конкретного светодиода в кубе.

Для начала рассмотрим управление восьмью светодиодами через регистр.

Пример программы по управлению светодиодами. Подключим 16 минусовых выводов на два регистра.
Четыре плюсовых вывода куба подключим к пинам 2,3, 4 и 5

Загрузим на плату программу, которая вызовет эффект бегущих огней в кубе.

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

Пример работы

Еще в 2018 наткнулся на довольно известный в своих кругах проект Пультоскоп. Если кратко, то это крайне примитивный осциллограф, построенный на arduino 328 серии. Учитывая его простоту, я его повторил за несколько часов на макетке и тут меня понесло... Но обо всем по порядку.

Итак. Повторенное устройство оказалось настолько нужным и удобным, что сама-собой возникла идея дополнить его базовыми функциями мультиметра, в том числе измеритель емкости конденсаторов и индуктивности катушек. В результате я начал работу над созданием идеального "под себя" устройства. Эмпирически прикинув функционал, который так или иначе задействую при проектировании своих устройств, я исключил ненужные мне функции и определил обязательные. В первую очередь, исходил из того, что в большинстве своем я не использую напряжения свыше 24 вольт и токи свыше 3 ампер. Обычно это низковольтное оборудование, IoT, ESP32, arduino и схожие по идеологии устройства. Соответственно и при измерении сопротивлений, емкостей и индуктивностей важна не столько точность, сколько понимание номинала и, желательно, автоматическое определение цветовой и кодовой маркировки. Обычно измерение этих параметров требуется при проектировании питающих схем устройств. Обязательна хотя бы минимальная проверка наличия данных на порту UART, а в идеале и их чтение. Здесь же я стал размышлять над формфактором устройства.

Собственно список того, к чему я пришел в итоге:

• Вольтметр с точностью измерения не выше 0.01 вольта. Обычно достаточно даже десятых долей. При этом, обязательно необходимо отображение значений логических уровней для CMOS1.8, TTL и CMOS5.0 вольт.

• Амперметр до 3 ампер с возможностью отображать график изменения значений.

• Измерение номиналов пассивных элементов. Одна из наиболее необходимых для меня вещей, оказалась возможность на лету отображать цветовую и SMD маркировку деталей. То же самое при измерении индуктивности и емкости, за исключением цветовой маркировки. Разумеется автовыбор диапазонов.

• Осциллограф обязателен. Как правило используется для измерения ШИМ сигналов, при проектировании питающих частей схем и при работе с данными для АЦП/ЦАП. Частоты как правило не выше 100кГц. Желательно что бы устройство само определяло триггер и настраивало масштаб графика.

• UART логгер с автоопределением скорости.

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

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

Звучит слишком идеально, но это хотя бы обозначенная цель.

ПРОЕКТИРОВАНИЕ

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

Это рендер. Первая игла щупа торчит из кончика корпуса, второй щуп втыкается в "попку" - любой подходящий с бананом.

Что касается железной части, то здесь пришлось сильно поломать голову. Первые версии были построены на ATMEGA32U4. Его выбрал из-за в встроенного USB и достаточной скорости. Но самым главным критерием была arduino совместимость. Я принципиально хотел использовать платформу arduino, поскольку сразу зародилась мысль выложить ПО в открытый доступ и при этом оно должно было быть понятным ардуинщику. В качестве датчика тока решил использовать ACS712. Остальное на резистивных делителях, там ничего интересного.

Одна из последних тестовых версий плат, собранных на коленке:

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

А это уже первый заводской прототип:

Виден не распаянный в верхней части блютуз модуль JDY-08. Использовал его потому, что был. В качестве встроенного зонда, использовал иглы для тестирования плат методом летающего щупа. Сам зонд выглядит так:

Игла немного подпружинена и не дает поцарапать медь или лак на плате.

Косяков было не так много, все довольно легко смог исправить кинув "сполю", но пришлось отложить проектирование из-за нехватки времени. Собственно это позитивно сказалось на проекте, поскольку удалось много поработать с ESP32, на него я и перевел устройство. Попутно заменил старый, 0,96 дюймовый дисплей с разрешением 80x160, на 1,14 дюймовую матрицу 135*240 пикселей.

Должен сказать, что я не сторонник сенсорных кнопок, и в первой версии устройства у меня были физически нажимаемые 3 кнопки, но пришлось себе изменить. Шутки ради собрал прототип с 3-х контактным сенсорным интерфейсом и воткнул его в отпечатанный на 3D принтере корпус. Оказалось, что проще и быстрее не искать пальцем нужную кнопку, а банальными свайпами переходить в нужный режим. Сразу возник соблазн использовать встроенные в ESP32 пины емкостного сенсора, однако их чувствительности оказалось недостаточно для работы в корпусе. Потому пришлось перейти на использование букашек от ttp223. Из-за катастрофической нехватки пинов, три сенсора я подключил через резистивный делитель на один аналоговый вход. Еще один пришлось вешать на отдельный пин для реализации выхода из сна по прерыванию. С аналоговым входом, на котором висят 3 сенсора возникла неожиданная проблема. Оказалось, что при включении режима bluetooth или WiFi , некоторые пины не могут читать аналоговые данные. На практике, при подключении к смартфону, устройство просто переставало реагировать на сенсоры. И все бы ничего если бы я хотя бы мог переразвести, но функции были раскиданы по пинам с учетом их специфики, и получалось, что любой пин к которому можно подключить сенсоры, оказывался именно тем, который не мог работать при включении радиомодуля. Но интернеты, таки помогли.

Немного пораскинув мозгами, пришел к выводу, что вместо ACS712, лучше использовать INA219. Во-первых управление по I2С, во-вторых возможность измерять напряжение до 26 вольт. При измерении сопротивления, обычно используют коммутируемые резистивные делители для разных диапазонов, эта же функция необходима при измерении ёмкости конденсаторов. Вариант использовать ограниченное число пинов для коммутации резисторов такой себе, вместо этого я поставил цифровой потенциометр на 100К AD5245. Таких в устройстве два. Второй регулирует чувствительность ОУ на входе. Второй щуп перенес в разъем для зарядки TYPE-C и несколько видоизменил корпус.

Внеся все эти изменения я заказываю плату на JLCPCB и сходу понимаю, что уже есть косяки. Но не смертельно. Вот что у меня получилось на этом этапе:

Ниже небольшой видеообзор:

Тут важно понимать, что этот прибор даже не пытается претендовать на высокую точность измерений. Речь идет о тех параметрах, которые минимально необходимы без упрощения до уровня пробника. Для меня здесь принципиальна простота и возможность кастомизации на уже готовом железе. Даже приложение для смартфона я собрал в App Inventor.

На сегодняшний день, у меня написан основной базис ПО. Пришлось повозиться с корпусом, зато смог максимально удешевить стоимость пресс-формы. Для понимания порядка цен, стоимость матрицы $5600, ресурс 300к отливок. Стоимость 1 отливки, включая заглушку на дисплей и подсветку рабочей зоны $1,53. Размеры ~120x22мм. Корпус цельнолитой из ABS с SoftTouch покрытием.

Но даже это для меня довольно дорого. возможно попробую обратиться к краудфандингу. Если тема будет интересна, готов периодически выкладывать статьи.

В этой статье я расскажу, как мне удалось заставить работать nRF пульты для ПК, для которых были утеряны приемники. Не обошлось без Arduino, множества попыток бросить это дело, долгого безуспешного гугления, радости маленьким победам, разочарования от неудач и наконец новой жизни для nRF пульта, но обо всем по порядку...

В далекой-далекой галактике...

Для начала, расскажу зачем мне вообще понадобился такой пульт. Будет много и длинно, кому это неинтересно, может сразу перейти к следующей главе. Дело, в том, что я все еще отношусь к той устаревшей модели людей, которые привыкли видеть компьютер центром всего мультимедиа в доме (как это было в середине 2000х) и хоть, теперь для каждой задачи уже давно есть свой гаджет, мне все равно так привычнее и удобнее. Поэтому фильмы я смотрю исключительно через ПК. У меня довольно древний 42' ЖК телевизор подключенный по HDMI, который я не вижу смысла менять на что-то новее. Если мне нужен большой экран - для этого у меня есть проектор и экран с диагональю в 2 метра (так же по HDMI к ПК). Но я уже давно на нем ничего не смотрел, он для чего-то такого эффектного, красивого, вроде Аватара, но что-то за последние пару лет я ничего такого интересного для себя не находил. А простые сериальчики можно глазеть и на экране поменьше, к чему эти огромные головы крупным планом? И вот, уже, наверное, лет 10 назад, попался мне первый пульт для ПК, шел он в комплекте к одной из материнок от ASUSа.

Он был маленький простой и удобный, и я тут же заценил, что больше не надо подрываться и нажимать кнопки на клавиатуре, чтобы поставить на паузу, прибавить громкость, увеличить скорость или мотнуть. Сейчас можно, конечно, использовать для этого Bluetooth клавиатуру или мышку, но я по прежнему вижу это менее удобным, чем использовать пульт. Клавиатура здоровая, на ней куча ненужных кнопок, ей не место на диване. Мышь надо по чему-то возить и еще высматривать там на экране курсор, а это бывает трудновато, когда курсор-то на экране, только вот на другом. А пульт просто взял в руку и нажал нужную кнопку, к которой уже привык и которую найдешь наощупь. Да можно еще поднять DLNA и использовать SmartTV, но там надо думать схавает ли телек этот формат, настраивать транскодинг, если нет (а транскодинг вообще зло, зачем так мучать видео). Поэтому, я очень долго использовал этот пульт (точнее не этот, это запасной, а тот который я использовал, уже слишком истерся и выглядит неприглядно, да, я не из тех людей, которые держат пульты в целлофане, в целлофане ощущения не те). И всем этот пульт был вроде хорош, но со временем мне стало не хватать на нем кнопок. И тогда я заказал с Али вот такой:

Его я использовал вместе с программой EventGhost для Windows, которая позволяет назначать на разные кнопки разные действия и поддерживает некоторые пульты, включая этот. Но вот был один недостаток - для того, чтобы этот пульт нормально работал внутри EventGhost и не делал больше ничего лишнего, для него нужно было поставить специальный драйвер, а драйвер этот был не подписан. Как известно Майкрософт это любит не очень и хоть и оставляет такую возможность, но приходится немного поплясать с бубном, перезагружаясь в тестовый режим, где этот драйвер надо ставить. При этом, во время крупных обновлений 10ки он зачастую слетал и приходилось проделывать это снова. Этот пульт служил мне еще несколько лет, но в какой-то момент, после очередного слета драйвера, мне это надоело и я решил попробовать что-то еще. Тогда я заказал с Али вот такое чудо:

Он уже работает на 2.4Ghz и не требует прицеливания, что конечно большой плюс, а вот минусом было то, что для него не было уже какого-то специального драйвера, который позволил бы мне назначить на каждую его кнопку именно те комбинации клавиш, которые мне нужны. Т.е. я конечно мог назначить на кнопку "домой" какое-то действие в EventGhost и оно выполнялось, но помимо этого кнопка "домой" срабатывала еще и как кнопка "домой" и открывала мне браузер с домашней страницей. Я даже нашел какую-то программу, которая позволяла мне заблокировать прямое назначение некоторых кнопок, на которые у меня были назначены макросы в EventGhost и это улучшило картину. Но я все еще не мог назначить действие на кнопки с цифрами, иначе они выполнялись, когда я нажимал эти цифры на обычной клавиатуре, и заблокировать я их не мог по той же причине. Позже я нашел древнюю программу HidMacros которая могла вешать действия на клавиши с какого-то конкретного устройства, и она даже работала под 10кой, но че-то программ стало слишком много для такой простой задачи и я снова стал бояться, что с очередным обновлением что-то из этого отвалится. К этому времени я как раз увлекся Arduino и понял, что могу сделать, чтобы любой ИК пульт работал у меня, как пульт для ПК. Я снова вернулся к предыдущему пульту, но теперь он передавал сигнал в ИК-приемник Arduino, а тот в свою очередь отдавал команду в EventGhost через ком порт. Единственное, что после 2.4Ghz пульта, использовать снова ИК, которым надо хоть не много, но прицеливаться было шагом назад, но я смирился. И все шло себе тихо-мирно, но вдруг, внезапно, мне достались эти красавцы:

Посмотрев на них и на их набор кнопок, я понял, что хочу чтобы хоть один из этих ребят работал на меня. Я вставил батарейки и радостно начал нажимать кнопки, но на ИК приемник ничего не приходило. И вот тут я понял - они не ИК, они такие же, как и VONTAR на картинке выше, работают на 2.4Ghz и без приемника с ними делать нечего, а приемников от них то у меня и нет. Можно было, конечно, заказать такой же пульт с приемником на Али, но я уже предвидел какие проблемы меня ждут: я снова не смогу нормально назначать действия на кнопки, они будут эмулировать те клавиши которые в них зашиты и только их. Снова надо как-то хитро блокировать прямое назначение этих клавиш, снова все не просто Plug и не просто Play, опять какие-то трудности. А я не люблю, когда трудности. Я люблю когда ахренительно-невероятно-пипец, какие трудности. Поэтому я заказал для Ардуино модуль nRF24L01+ и раз уж нам подарили с барского плеча столько выходных на майские, а погода как-то не все дни обещает быть хорошей, я решил потратить часть этого времени, чтобы хакнуть протокол пультов!

Этап принюхивания

Итак, мой модуль nRF24L01+ пришел, я достал одну из Ардуино нано и был готов перехватывать пакеты!

Ну вот теперь я точно был готов к перехвату пакетов, но вот пакеты оказались не готовы быть перехваченными. Это было первое разочарование. Вообще модуль nRF24L01+ я брал наугад, типа тут 2.4Ghz, там 2.4Ghz, ну... давайте... работайте вместе как нибудь! Ну пожалуйста! Но, как выяснилось, протоколов этих очень много, те же модули WiFi работают на этих частотах, но пакеты от пульта получать в большинстве своем не могут. И если пульт шлет свои пакеты не по тому протоколу, по которому работает nRF24L01+, то тоже ничего не выйдет. Я понадеялся на удачу и для начала стал искать канал, на котором должны идти данные. Для этого я скачал какой-то нагугленный скетч в интернете, который смотрит на каких каналах есть сигналы. Как оказалось сигналы есть много на каких, но нажатия кнопок на пульте никак на них не влияет. Сигналов больше не становиться ни на одной из частот, а они хаотично появляются на разных частотах, не зависимо от того, нажимаю я что-то на пульте или нет. У nRF24L01+ есть 3 скорости 250Kbit, 1Mbit и 2Mbit. Ни на одной из них и ни на одном из каналов, я пульта не нашел, сколько бы не давил не его кнопки. "Ну что ж", сказал я себе, значит не судьба, и лег спать. Но на утро интерес снова проснулся, и я решил разобрать один пульт и посмотреть, что там все-таки за чип. К моей радости пульт, хоть и собран без единого винтика, но разобрался очень легко:

И что же я вижу на плате?

Именно! Там чип nRF24LE1G, внутри которого сидит nRF24L01. Значит все верно, и протокол тот. Но почему же, я не могу понять на какой частоте он работает? Пульт точно рабочий (когда я нажимаю кнопку, на нем моргает лампочка. А раз лампочка моргает - значит и пульт работает. И не говорите, мне что это не обязательно так!). Я потратил на это еще пару часов, но никаких результатов не добился и тогда я понял:

если уже больше ничего не помогает - прочти наконец этот чертов код, который ты скопировал из интернета и бездумно вставил в свой проект!

И я стал смотреть код и понял в чем причина. Модуль не умеет одновременно случать все частоты, поэтому код написан так, чтобы модуль постоянно переключался с одной частоты на другую слушая каждую по 128мкс. Но частот много, и получается, что те сигналы, которые генерит пульт, не успевают попадать под сканирование или попадают, но в очень малом объеме, не отличимом от общего шума. В результате я переписал скетч, чтобы частоты переключались вручную ('w' в COM порт - следующая, 's' - предыдущая), и о чудо! Уже на первом же канале, я увидел изменения при нажатии кнопок пульта. На втором канале, сигналов при нажатии стало еще больше, на 3м еще, а к 7му все прекратилось. Значит золотая середина - это канал номер 3, по нему и идут данные. Сканер, который получился в итоге выложил сюда:

https://github.com/CodeName33/NRFRemote/blob/main/NRF24Scanner.ino

Итак, пол дела сделано (я так думал), пульт работает по нужному протоколу и частота найдена, осталось только получать данные и использовать их! Как все просто в ожидании. Теперь реальность. Все не так! Как оказалось, nRF24L01 это не вай-фай и в нем нельзя сказать "получай все". Он требует задания скорости, канала и адреса, и без этого ничего получать не будет. Канал я уже знаю, осталось две переменные, скорость и адрес, и если первое можно подобрать (их всего три), то на подбор второго (адрес от 3х до 5 байт) уйдут всего лишь, миллиарды лет. Как хорошо, что они у меня, есть, погнали! (нет). Путем гугления выяснилось, что модуль можно немного обмануть. Адрес может быть от 3х до 5байт, но если передать ему, что длина адреса 2 байта, а само значение 0x55 или 0xAA, то можно таким образом получать все! В одном из случаев данные будут сдвинуты на 1 бит (в зависимости от того, как они передаются передатчиком). Ну что ж, начнем с адреса 0x55 и скорости в 2Mbit и к моему удивлению, это сработало с первого раза, я тут же стал получать кучу пакетов, а зажав кнопку на пульте, я заметил, что среди этих пакетов стали появляться пакеты с однотипным началом:

Естественно, я тут же поставил фильтр по этим 4 первым байтам и о чудо! Пакеты начали появляться, только при нажатии кнопок с пульта:

Успех был так близко, осталось только запомнить какие данные идут от каких кнопок и все решено, но вот тут возникла проблема. При нажатии на одну и ту же кнопку, каждый раз приходили разные данные, точнее если отсеять мусор в конце, я заметил 2 варианта и по началу я решил, что добавлю их оба, но позже, уже начав добавлять коды всех кнопок, я понял, что вариантов уже не 2, а 4. И добавлять на каждую кнопку все 4 варианта кодов было не круто. Да и вообще, не круто распознавать кнопку по данным сырого пакета, надо этот пакет хотя бы расшифровать. Возможно я в нем найду неизменные данные, по которым гораздо проще смогу определять, какая кнопка был нажата. И если формат самой секции данных в пакете знает только производитель пульта (HP), то формат пакета nRF24L01 секретом не является, вот он:

По этой схеме я и стал пытаться разобрать данные:

И все бы тут хорошо и адрес постоянный и доп адрес (5й байт адреса) меняется в зависимости от группы нажатой кнопки, но вот размер данных, я честно пытался взять его из чисел 13, 12, 159 и 130 извлекая 6 бит. Но выходил полный бред, 12 и 13 давали число 3, что явно слишком мало, а 159 - это 39, что явно нарушает все правила протокола, допускающего не более 32 байт данных. Притом, что данные внутри пакета дальше шли даже вроде и не плохо. Чертов Packet Control Header занимает именно 9 бит, и это значит, что все байты дальше надо сдвигать на 1 бит, что я и делал. И вроде все похоже. Но не совсем. Все равно на одну и ту же кнопку, я получал разные данные, странные данные, хотя часть из них выглядела очень правдоподобно. Но времени было уже около 3х ночи, и еще через 3 часа первые петухи начнут петь о том, какой я лошара, и мне нечего будет им ответить. Совсем нечего. На этом я плюнул, и лег спать. Утро вечера мудренее, я уже не раз в этом убеждался и решил, поверить этой пословице снова.

Этап вязки

Мое утро настало позже, чем я ожидал, но все таки подкинуло еще пару идей, я снова начал изучать эти цифры, пытаться крутить биты туда-сюда, понять что я упустил, но все подтверждало то, что у меня все было правильно, а картина все равно не сходилась. Я потратил еще пару часов и результат был нулевой. Черт, что же не так? Я же вроде не дурак? У меня даже справка есть! Мне её выдавали, когда я права менял. С тех пор не должно было ничего сильно измениться. Я еще раз понажимал две соседние кнопки на пульте и кажется начал кое-что понимать. Одна кнопка давала что-то типа последовательности 247 0 где-то в середине данных, другая 246 128 на тех же позициях. 247 и 246 это наверное коды кнопок, они рядом, логично, что соседние кнопки имеют отличие на кода единицу. Но вот следующий байт это 0 в одном случае и 128 в другом. Но ведь 0 это 00000000 по битам, а 128 это 10000000. Такое ощущения что эта единица заехала сюда зря, она из предыдущего байта. Но я точно все правильно смещаю, на 1 бит, как и должно быть, без смещения было еще хуже, было вообще 01000000, что равно 64... Стоп! Все если и правда все смещено еще на 1 бит! Ведь именно этим и отличаются адреса 0x55 и 0xAA которые используются для "хакерского" приема всех пакетов.

Флешбэк:

Адрес может быть от 3х до 5байт, но если передать ему, что длина адреса 2 байта, а само значение 0x55 или 0xAA, то можно таким образом получать все! В одном из случаев данные будут сдвинуты на 1 бит (в зависимости от того, как они передаются передатчиком)

Я определенно дурак, я ведь уже пробовал менять 0x55 на 0xAA до этого, но в этом случае у меня вообще переставали приходить мои пакеты... А они так и должны были сделать! Все сдвинулось на 1 бит, и адрес тоже, а я продолжаю фильтровать пакеты по первым байтам 65, 223, 152, 111, а они тоже меняются! Я отменил фильтр и снова нашел адрес пульта в море сигналов, он и правда стал другим:

И наконец-таки, поле с размером данных стало адекватным, теперь пакеты можно расшифровать:

Но самое главное, теперь при нажатии одной и той же кнопки, данные всегда приходят одни и те же (на самом деле не всегда, а почти всегда, но это уже ошибки связанные с загруженностью 2.4Ghz канала, по идее должно отсеиваться, если проверять CRC). Далее я забил данные всех кнопок в массив, чтобы их распознавать, и при нажатии кнопок в порт стали выводиться адекватные данные, с которыми, в свою очередь можно работать в EventGhost:

Я научился понимать, какие коды соответствуют нажатию клавиши, а какие тому, что все клавиши в группе отпущены. Это важно, для того, чтобы можно было делать авто-повтор нажатия для некоторых клавиш при их зажатии на пульте (перемотка, например или громкость), а для некоторых не делать (Play/Pause, например). В EventGhost все настраивается очень просто, для начала добавляется плагин ком-порта:

Дальше все что приходит из этого ком-порта можно видеть в логе программы:

И назначать макросы на эти события:

Итоговый результат скетча здесь:

https://github.com/CodeName33/NRFRemote/blob/main/NRF24Remote.ino

CRC, я все же решил не проверять, т.к. при включении его проверки (вариант с 1 байтом CRC) почему-то отсеивается довольно приличная часть пакетов, которая на самом деле имеет вполне себе валидные данные внутри. Может быть что-то еще можно подкрутить, но пока сойдет и так. Еще у пульта выявился еще один неприятный момент: Часть его кнопок работает довольно странно (крестовина и цифры). После нажатия одной из этих кнопок, пульт довольно долго шлет еще какие-то команды и ту команду, которую я посчитал за "кнопка больше не нажата", он может присылать с задержкой до 1 сек. Это очень много и можно поставить крест на быстрой навигации стрелочками (она стала медленная). Вероятно это как-то связано с особенностями его работы, может быть приемник ему, что-то должен отвечать, а может я что-то неверно понял, но на данный момент мне не удалось это победить. Возможно, еще поковыряю.

В будущем хочу отказаться от EventGhost и перевести проект на Arduino Pro Micro, которая умеет прикидываться USB клавиатурой и сразу отправлять нужные нажатия клавиш, работая без посредников. В этом случае пульт сможет работать не только в разных ОС, без доп. программ, но и с телевизорами и Андроид устройствами. Но пока все так, как есть. Спасибо за внимание!

Предупреждение ( некий АХТУНГ, так сказать)

Я не являюсь автором ПО и, тем более, не зазываю Вас повторять подобные устройства, так как это может быть запрещено законом и преследуется наказанием. Спасибо.

Вступление

Я в свои практически 20 лет (на момент написания статьи - через 3 дня) уже как года 4 слежу за всякими интересностями на Ардуино и околоАрдуинных платах для разработки. Сначала купил Нанку, с которой не понимал, что делать, потом поступил на разработку ПО и начал понимать, шо да как. От этого мой интерес увеличился настолько, что это стало моим хобби. Да, я не силён в программировании до сих пор, так как я банально прогуливал пары, но зато у меня есть база, так сказать основа, с помощью которой я снова вхожу в программирование через визуализирование этого во всяких поделках на Ардуино и им подобных. Мне не нравилось программирование из-за того, что результат ты увидишь далеко не сразу, а с помощью микроконтроллеров этапы готовности можно посмотреть прямо на глазах, да и потрогать, пощелкать, попереключать.

Перейдем к железу

По железу все банально и просто: Китайский клон Wemos D1 Mini на базе ESP8266, I2C дисплейчик 128х64 и две кнопки, которые я вырвал с китайской магнитолы. В оригинале их 3, но у меня не влазило в корпус, поэтому решил оставить только кнопку "ок" и "вниз", так как если долистать меню до конца, то указатель начнет с самого начала. Да, больше времени уходит на листание менюшек, но зато компактнее .

Прошивка

Прошивку можно скачать по ссылочке ( ТЦ )

Так же там имеется подробная инструкция для таких, как я XD

Я не буду заостряться на подробностях настроек до прошивки, в конфиге все банально ясно. Есть два вида файлов: .bin, который шьется NodeMCU Flasher и исходный код со скетчем ардуино. Я использовал скетч, что бы настроить подключение дисплея, переназначить кнопки и изменить названия.

Корпус

Изначально я раскурочил старый 3G модем от МТС (который сейчас в Украине Vodafone), вырезал отверстия под дисплей и кнопки. Ровно после финальной сборки я понял, что выглядит не очень: кривые вырезы, лишние размеры для дисплея, болтающиеся кнопки, корпус плохо закрывался, питание подключалось путем разгибания нижней части корпуса. Короче, не комильфо. Надо думать что-то новое.

Новый корпус и формфактор.

Решил я размещать компоненты не в одной плоскости, а бутербродом. Более подробные фото сборки показывать не буду, ибо это бешенный колхоз, так как в распоряжении у меня был только малярный нож, паяльник и клеевой пистолет с изолентой. Материалы корпуса - пластик, вырезанный с корпусов старых телефонов, которых у меня целый пакет и горстка. Собирал все на секундный суперклей для надежности паял пластик обычным паяльником. Ничего нового, короче. Позже зашкурил наждачкой и покрасил с баллончика.

По размерам устройство получилось 3х4см с учетом вылета кнопок с корпуса. И это меня очень радует. У меня не было конкретной цели собрать джаммер, я просто хотел своими руками сделать какое-то крутое устройство, да и еще в подобных размерах.

Возможности

Вкратце пройдемся по функциям новоиспеченного утройства, так как более подробная информация есть в источнике, упомянутом несколькими разделами выше.

• Сканирование сетей и устройств ( если они подключены к сетям) с последующим просмотром количества отправляемых пакетов, MAC-Адреса и мощность сигнала.

• Атака путем деаутентификации как полностью всей сети, так и конкретного устройства по MAC-адресу

• Режим "Бекон", который создает до 80 точек доступа, названия которых можно скопировать с существующих сетей, записать свои или создать с помощью встроенного генератора.

• Режим "Probe" с которым я так и не разобрался, да и фиг с ним )

Помимо управления с помощью дисплея и кнопок, существует так же Веб-интерфейс. Устройство создает точку доступа, вы к ней подключаетесь, вводите в браузере Deauth.me и попадаете на страницу, похожую на веб-интерфейс роутера, в котором гораздо больше настроек, в отличии от автономного использования джаммера.

Выводы

Хоть моей целью не было воспроизведение конкретно этого устройства - результатами я очень доволен, так как это моё первое самодельное устройство, размеры которого не превышают распределительную коробку из строй магазина за 15 гривен

P.S. Чуть позже запишу видео, как сие чудо техники работает на примере своей точки доступа и ноутбука

В первой статье я в общих словах познакомил читателей с устройством. Сегодня расскажу о примененных технических решениях и о том, какого прогресса добился в вопросе выхода на рынок. Но для начала хочу сказать спасибо всем тем, кто откликнулся и дал полезные советы к предыдущей статье. И это не дежурная благодарность, я действительно использовал советы читателей по улучшению прибора и об этом, так же, пойдет речь ниже.

Для начала напомню, что собой представляет устройство. QUARK это электронный мультиинструмент, в первую очередь, ориентированный под разработку микроконтроллерных устройств, Arduino, ESP32, STM32, IoT, домашняя автоматизация и тому подобные девайсы.

Че определяется такая ориентированность? Во-первых, набором функций. И если первая часть стандартна для типичного мультиметра:

Вольтметр

Амперметр

Измерение сопротивления

Измерение емкости

Измерение индуктивности

то UART логгер и UART плоттер вещи необходимые ардуинщикам и иже с ними. Осциллограф конечно не блещет скоростью 400 килосемплов, однако проверки ШИМ сигналов и сигналов с различных датчиков, его более чем достаточно.
Во-вторых идеологией работы с выводимыми значениями. Скажем, ардуинщику практически никогда не требуется знать напряжение с точностью в одну тысячную процента, зато значение логического уровня параметр всегда необходимый:

Точно так же мгновенное потребление тока, при разработке IoT, параметр в себе. Гораздо удобнее проследить изменение в динамике при различных режимах работы устройства:

Калькулятор цветовой и СМД маркировки компонентов вещь полезная и нужная, но, согласитесь, так удобнее:

А сейчас опишу свой личный опыт работы с осциллографом. В свое время приобрел себе DS203. Вполне себе, по характеристикам, годный девайс, с жутко неудобным управлением:

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

UART данные, конечно, удобнее смотреть на телефоне чем на дисплее устройства. Не скажу, что я прям мучаюсь при подключении UART-TTL моста к компу, но в поле не всегда имеется такая возможность:

Теперь пару слов о схемотехнике. Вся система построена на ESP32 со всеми вытекающими из нее ништяками (bluetooth, Wi_fi). Для измерения напряжения и тока я использовал готовый чип INA219. Подключается по I2C шине, имеет малый размер и вполне достойные, для моих задач, параметры. Сопротивление измеряю стандартным делителем напряжения, но в качестве известного сопротивления использую цифровой потенциометр AD5245, что освобождает пины контроллера, а учитывая тот факт, что AD5245 управляется по I2C, так и вообще нет нужды в дополнительных пинах. Тем же способом измеряю емкость конденсаторов по известному методу заряда до 63.2%. На больших емкостях AD5245, подключенное к питанию имеет низкое сопротивление, а при низких, заряд идет через 1 мегаомный резистор. Таким образом, минимальная измеряемая емкость определяется пикофарадами.
Индуктивность меряю резонансным методом при известной ёмкости по срабатыванию компаратора.
Тракт осциллографа реализован на Rail-to-Rail ОУ AD8541, усиление сигнала регулируется вторым AD5245. Соответственно, сигналы как с высоким, так и с низким размахом амплитуды, поступают на вход АЦП в максимальном разрешении. Для оцифровки использую аппаратный I2S, складываю весь буфер в DMA и вывожу на LCD и, при необходимости, отсылаю по bluetooth.

UART вход реализован аппаратно. Предварительно определяется Baud rate, после чего происходит инициализация драйвера UART с определенными параметрами.
На плате присутствует датчик ускорения LSM6DS3TR. Вообще я его планировал использовать для автовыключения, но ничто не мешает вывести с него данные на экран.

А теперь хотелось бы сказать пару слов о тех нововведениях, которые были реализованы на основе предложений к предыдущей статье.

Во-первых, универсальный прикручиваемый щуп:

Такие будут как в корпусе, так и во втором щупе. Довольно универсальное решение на стандартной резьбе М2.
Во-вторых, расширен функционал: поиск компонентов по заранее введенному значению и удержание значений с записью в лог.
И в-третьих, вариант без корпуса, этакий кит-набор, но распаянный.

Ну и самое главное. По-совету читателей я таки запустился на краудфандинговой платформе Crowdsupply. Некоторое время вел переговоры, совместно настраивали страницу и готовили описание. Платформа ориентирована на железные open source проекты, а значит и мое устройство будет выложено в открытый доступ. Всех, кому проект интересен приглашаю поддержать старт и тут я снова сделаю упор на том, что это open source.

Привет, Хабровчане!

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

О чем речь?

Задача состояла в подключении файлов: HTML, JS, CSS; без специальной подготовки. Так же неудобно подключать бинарные файлы (например картинки) конвертируя их в HEX. Так как не хотелось конвертировать в HEX или разделять на строки, искал способ подключения файла в адресное пространство программы.

Как обычно это выглядит

Пример, c разделением строк:

const char text[] =    "<html>"            "\r\n"    "<body>Text</body>" "\r\n"    "</html>";

Пример, с HEX (больше подходит для бинарных данных):

const char text[] =    {        0x3C, 0x68, 0x74, 0x6D, 0x6C, 0x3E, 0x0A, 0x3C,        0x62, 0x6F, 0x64, 0x79, 0x3E, 0x54, 0x65, 0x78,        0x74, 0x3C, 0x2F, 0x62, 0x6F, 0x64, 0x79, 0x3E,        0x0A, 0x3C, 0x2F, 0x68, 0x74, 0x6D, 0x6C, 0x3E,        0    };

Видел даже такое:

#define TEXT "<html>\r\n<body>Text</body>\r\n</html>"const char text[] = TEXT;

Все #define располагались в отдельном .h файле и подготавливались скриптом на Python. С аннотацией, что некоторые символы должны бить экранированы \ вручную в исходном файле. Честно немного волосы дыбом встали от такого мазохизма.

А хотелось, чтобы файлы можно было спокойно редактировать, просматривать и при компиляции всё само подключалось и было доступно, например так:

extern const char text[];

Оказалось всё просто, несколько строчек в Assembler.

Подключаем файл в Arduino IDE

Добавляем новую вкладку или создаём файл в папке проекта с названием text.S, там же размещаем файл text.htm.

Содержимое файла text.htm:

<html><body>Text</body></html>

Содержимое файла text.S:

.global text.section .rodata.myfilestext:    .incbin "text.htm"    .byte 0

Не забываем нулевой символ \0 в конце, он здесь в строке сам не добавится.

Сам скетч:

extern const char text[] PROGMEM;void setup(){    Serial.begin(115200);    Serial.println(text);}void loop() { }

Компилируем, загружаем и смотрим вывод:

Отлично, когда-то бы я от радости прыгал до потолка, от того что всё получилось.

Код работает в AVR8, но например в ESP8266 получим аппаратный сбой. Всё потому, что чтение из Flash доступно по 32 бита и по адресам кратным 32 бит. Чтобы было всё хорошо, каждому файлу требуется делать отступ для кратности, код будет выглядеть так:

.global text.section .rodata.myfiles.align 4text:    .incbin "text.htm"    .byte 0

Загрузить можно в секцию кода: .irom.text, если не хватает места в .rodata.

Для STM32 так же рекомендуется выравнивать по 32 бита, но не обязательно.

А как записать размер данных во время компиляции? Например, для бинарных данных не получится остановится по нулевому символу. Так же просто:

.global text, text_size.section .rodata.myfilestext:    .incbin "text.htm"    text_end:    .byte 0text_size:.word (text_end - text)

Объявление:

extern const char text[] PROGMEM;extern const uint16_t text_size PROGMEM;

Осталось написать макрос, для удобства подключения файлов:

.macro addFile name file    .global \name, \name\()_size//  .align 4    \name:        .incbin "\file"        \name\()_end:        .byte 0//  .align 4    \name\()_size:        .word (\name\()_end - \name).endm.section .rodata.myfilesaddFile text1   1.txtaddFile text2   2.txtaddFile text3   3.txt

И макрос для объявления:

#define ADD_FILE(name) \    extern const char name[] PROGMEM; \    extern const uint16_t name##_size PROGMEM;ADD_FILE(text1);ADD_FILE(text2);ADD_FILE(text3);void setup(){    Serial.begin(115200);    Serial.println(text1);    Serial.println(text1_size);    Serial.println(text2);    Serial.println(text2_size);    Serial.println(text3);    Serial.println(text3_size);}void loop() { }

Вывод:

Таким образом можно подключить любой файл и представить его любым типом, структурой или массивом.

Подключаем любой файл и не только, в GNU toolchain

Принцип тот же самый, ни чем не отличается для Arduino. В принципе в Arduino используется тот же toolchain от Atmel.

Только здесь у нас в руках Makefile и мы можем до компиляции и сборки запустить какой-нибудь скрипт.

Для примера возьму код из готового моего проекта на STM32, где автоматически при компиляции увеличивается версия сборки. Так же включаются в проект WEB-интерфейс для последующего использования в LWIP / HTTPD.

Скрипт version.sh:

#!/bin/bash# Version generator# running script from pre-buildMAJOR=1MINOR=0cd "$(dirname $0)" &>/dev/nullFILE_VERSION="version.txt"FILE_ASM="version.S"BUILD=$(head -n1 "$FILE_VERSION" 2>/dev/null)if [ -z "$BUILD" ]; thenBUILD=0elseBUILD=$(expr $BUILD + 1)fiecho -n "$BUILD" >"$FILE_VERSION"cat <<EOF >"$FILE_ASM"/*** no editing, automatically generated from version.sh*/.section .rodata.global __version_major.global __version_minor.global __version_build__version_major: .word $MAJOR__version_minor: .word $MINOR__version_build: .word $BUILD.endEOFcd - &>/dev/nullexit 0

Создаётся файл version.S в который из version.txt загружается номер версии предыдущей сборки.

В Makefile добавляется цель pre-build:

######################################## pre-build script#######################################pre-build:bash version.sh

В цель all надо дописать pre-build:

all: pre-build $(BUILD_DIR)/$(TARGET).elf $(BUILD_DIR)/$(TARGET).hex $(BUILD_DIR)/$(TARGET).bin

Объявление и макросы для printf у меня в macro.h:

extern const uint16_t __version_major;extern const uint16_t __version_minor;extern const uint16_t __version_build;#define FMT_VER             "%u.%u.%u"#define FMT_VER_VAL         __version_major, __version_minor, __version_build

В HTTPD из LWIP немного был удивлён когда увидел, что содержимое файлов надо хранить вместе с заголовками HTTP. Чтобы не менять архитектуру, загрузку делал как это организовано в примере fsdata.c. Использовал fsdata_custom.c, для этого установлен флаг HTTPD_USE_CUSTOM_FSDATA.

Код в fsdata_custom.c:

#include "lwip/apps/fs.h"#include "lwip/def.h"#include "fsdata.h"#include "macro.h"extern const struct fsdata_file __fs_root;#define FS_ROOT &__fs_root

Сборка файлов fsdata_make.S:

.macro addData name file mime\name\():.string "/\file\()"\name\()_data:.incbin "mime/\mime\().txt".incbin "\file\()"\name\()_end:.endm.macro addFile name next\name\()_file:.word \next\().word \name\().word \name\()_data.word \name\()_end - \name\()_data.word 1.endm.section .rodata.fsdata.global __fs_root/* Load files */addData __index_htm         index.htm           htmladdData __styles_css        styles.css          cssaddData __lib_js            lib.js              jsaddData __ui_js             ui.js               jsaddData __404_htm           404.htm             404addData __favicon_ico       img/favicon.ico     icoaddData __logo_png          img/logo.png        png/* FSDATA Table */addFile __logo_png          0addFile __favicon_ico       __logo_png_fileaddFile __404_htm           __favicon_ico_fileaddFile __ui_js             __404_htm_fileaddFile __lib_js            __ui_js_fileaddFile __styles_css        __lib_js_file__fs_root:addFile __index_htm         __styles_css_file.end

В начале каждого файла загружается заголовок, пару примеров из папки mime.

Файл html.txt:

HTTP/1.1 200 OKContent-Type: text/html; charset=UTF-8Connection: close

Файл 404.txt:

HTTP/1.1 404 Not foundContent-Type: text/plain; charset=UTF-8Connection: close

Нужно обратить внимание на пустую строку, чего требует спецификация HTTP для обозначения конца заголовка. Каждая строка должна заканчиваться символом CRLF (\r\n).

P.S. Код проекта из ветхого сундука, так что в реализации мог забыть чего ни будь уточнить.

В завершении

Долго искал, что изложить в статье полезного. Надеюсь мой опыт пригодится новичку и гуру.

Спасибо за внимание, удачных разработок!

Я хочу рассказать о одном из способов управлять беспроводной электрикой NooLite с помощью голосового помощника и смартфона (плюс как бонус с компьютера или любого ИК-пульта без Интернет-шлюза).

Вся электрика в квартире и на даче у меня построена на системе NooLite. Почему именно NooLite? Начну издалека. С продукцией фирмы "Ноотехника" я познакомился еще в прошлом веке. Это были блоки защиты галогенных ламп. Они мне очень понравились - свет включался плавно и лампы служили намного дольше. Но вскоре на смену галогенным лампам пришли люминисцентные и блоки защиты стали неактуальны. Потом в квартире был ремонт, стоивший мне немало седых волос и когда через некоторое время возникла необходимость перенести и добавить выключатели, одна мысль о штроблении стен, пыли, грязи и переклейке обоев просто ввергала меня в ужас. Именно тогда я и познакомился с системой беспроводного управления освещением от NooLite. В то время еще не было Xiaomi, Sonoff, Tuya и других недорогих альтернативных решений. Были системы умного дома от европейских серьезных производителей, но там цена вопроса была просто неадекватной. Я решил все свои проблемы с переносом выключателей, разбиением освещения на зоны, сценариями освещения, проходными выключателями, включением-выключением вентиляции и удаленным управлением светом в сараях и гараже на даче с помощью самых первых NooLite, без шифрования и обратной связи.

Все что я сделал много лет назад работает до сих пор, батарейки в пультах менял 1 или 2 раза, в зависимости от интенсивности пользования. Потом добавился беспроводной датчик движения на двери в туалете, позволяющий маленькому ребенку без страха ходить туда (свет включается уже при начале открывания двери) и автоматически выключающий свет и таймеры в туалете и ванной, включающие вытяжку через заданное время после зажигания света и поддерживающие ее включенной некоторое время после выключения. Одно время я крепко задумался о настоящем "умном доме", купил несколько силовых блоков, пультов, датчики температуры и влажности, продумывал структуру. Но потом передумал, так как понял что в не такой уж большой двухкомнатной квартире мне это не нужно. Я так и остался верен системе NooLite, хотя сейчас хватает альтернатив и некоторые из них дешевле и выглядят, возможно, современнее чем изделия Ноотехники. Но тут у меня есть определенные условия. Во-первых, управление моим освещением и электронными устройствами не должно зависеть от китайского облака и вообще от наличия/отсутствия Интернет, тем более что в последние месяцы у нас в городе практикуется периодическое его отключение или замедление (Интернет и wi-fi только как бонус в управлении). Во-вторых, я не хочу держать постоянно включенными узкоспециализированные шлюзы и компьютеры, и так хватает устройств, которые включены постоянно. В-третьих, для меня очень важны надежность и гарантия, больше чем цена. У меня сами по себе перестали функционировать две розетки SmartPlug от Хiaomi и я не смог их починить. Пришлось выбросить. Вышедшие из строя силовой блок и таймер для санузлов в Ноотехнике мне просто поменяли на новые, не уточняя кончилась ли гарантия и не спрашивая при каких условиях они перестали работать (при проведении экспериментов бывает всякое). Это Lifetime warranty в том виде, в котором она мне нравится. Ну и в-четвертых, дополнять уже работающую и хорошо зарекомендовавшую себя систему, проще и легче чем городить что-то другое.

Сейчас уже вовсю используется новое поколение NooLiteF с обратной связью и шифрованием, но для пользователя мало что поменялось, монтаж, привязка и отвязка такие же простые, надежность тоже вроде на высоте. А обратная связь, прошивка "по воздуху" и возможность считать состояние устройства это бонус, кому-то нужный, кому-то нет.

Вроде все хорошо, но сейчас мне уже хочется, как дополнительную опцию, иметь иногда возможность управления NooLite через Интернет. Такая опция у Ноотехники есть. И даже существуют приложения для смартфонов под Android и iOS. Но для этого нужно докупать Интернет-шлюз PRF-64 или контроллер PR-1132, которые стоят больше $100 и должны быть все время включены. Это еще одно постоянно включенное в розетку устройство с весьма узкими возможностями. А с появлением дома умной колонки с голосовым помощником Алиса, захотелось "подружить" Алису с NooLite.

Раз хочется сделаем. Для начала я забил в поиск Гугла " NooLite и Алиса". Зачем изобретать велосипед, вдруг уже давно все решено? И да, мне выдало несколько уже готовых решений, но все они показались мне излишне сложными. Вот например:

На Хабре есть статья "Обход noolite роутера через mtrf64+esp8266+MQTT Buddy Android app".

Там сказано что модуль mtrf64 подключен по UART к esp8266, которая в свою очередь выходит в интернет через ваш роутер и подключается к MQTT бесплатному брокеру. Вы, как пользователь, через мобильное приложение так же подключаетесь к этому облачному брокеру и начинаете посылать команды в MQTT каналы, которые в свою очередь разбираются на лету и в зависимости от команды передаются по UART MTRF64 модулю. Проблему управления через Интернет без дорогостоящего и узкоспециализированного интернет-шлюза от Ноотехники это решает. Но "бесплатный облачный брокер" в связке с ESP8266 почему-то не вселяет в меня уверенности в надежности. Да и голосовое управление прицепить будет непросто (или невозможно?). А значит мне не подходит.

Второе решение реализовано через цепочку навык "Домовенок Кузя"-IFTTT-IHC-шлюз Broadlink (то есть все равно покупка шлюза)-NooLite.

Перспектива регистрации на всех этих сайтах и прописывания настроек меня как-то не воодушевила. Надежность работы такой дли-и-и-нной цепочки тоже не внушает мне доверия. Да и задержка исполнения 3 сек. и более напрягает. Хочется более простого и изящного решения без такой длинной цепочки.

Я начал думать и ставить себе задачу. Покупать какие-то шлюзы без уверенности что это мне нужно и я буду этим пользоваться не хочется. Значит нужно делать из того что есть в наличии. А что у меня есть?

1. Колонка IRBIS с голосовым помощником Алиса.

2. Несколько силовых блоков первой серии без обратной связи.

3. Модули MT1132 и MTRF-64 для управления NooLite и NooLite-F c помощью контроллеров.

4. Несколько плат Arduino.

Не густо. Логическая цепочка не просматривалась до тех пор пока мне на глаза не попал умный пульт Яндекса. И сразу все встало на свои места. Яндекс напрямую работает со своим пультом, а тот умеет записывать любой ИК-сигнал и передавать его по команде. К Arduino подключены ИК-приемник и модуль управления системой NooLite. По-моему, гениально проще некуда. Умный пульт от Яндекса стоит меньше чем $20 и это устройство универсальное, может использоваться для управления другой техникой (кондиционер, телевизор, ресивер и т.п.), а значит покупка его не бессмысленна. Вероятно, точно также будет работать и универсальный пульт от Tuya, который стоит еще дешевле, но после знакомства с умной колонкой IRBIS (звук и микрофоны у нее довольно посредственные а часть сервисов Яндекса не работает) я убедился что лучше заплатить дороже но взять оригинал, есть вероятность что будет выше качество и меньше глюков. Поэтому пульт выбрал оригинальный от Яндекс, не хочется взять стороннее решение, сэкономить пару долларов и узнать что снова часть функций не работает.

Теперь о модулях управления NooLite. У меня в наличии есть несколько вариантов модулей, которые можно подключить к контроллеру (Arduino).

По сути MTRF-64 и MTRF-64-USB это одно и то же. Просто у MTRF-64 незапаяна часть деталей и отсутствует корпус и USB разъем, но присутствуют пины.

Модуль MTRF-64, как видно из названия, 64 канальный, может отправлять команды старой системе без обратной связи и отправлять команды и принимать ответ новой системе с шифрованием и обратной связью.

MTRF-64

Технически сделано так, что именно с Arduino MTRF-64 использовать неудобно. Arduino запитывается напряжением 5В а MTRF-64 - 3,3В. Потребуется отдельное питание (на плате не запаян стабилизатор питания 3,3В, хотя место под него есть), отстутствует согласование уровней UART (это ведь не сложно предусмотреть и пара транзисторов практически не увеличила бы цену модуля).

MTRF-64-USB то же самое с запаянной на плате микросхемой переходника USB-UART и еще кое-какими деталями.

MTRF-64-USB

Смысл существования данного контроллера мне вообще малопонятен. Я слабо себе представляю как его реально можно использовать.

Казалось бы, отличная вещь, позволяющая упростить и ускорить процесс отладки проектов. Подключил в USB, посылай из терминала в COM порт последовательности... Но у меня так сделать не получилось. В техдокументации на контроллер такая возможность тоже не описана. Чтобы работать с контроллером есть специальная программа nooLite_ONE. Ее можно скачать с сайта Ноотехники. Но это если найдете, потому что со страницы самого контроллера ссылки на нее на данный момент нет.

Теперь про саму программу. Я не знаю кто ее написал, но она ужасна. Внешний вид и цветовые решения наверняка вызовут у больного эпилепсией приступ. Внутри - куча несуразностей. Такое чувство что просто взяли сервисную программу, которой пользовались разработчики и сообщения которой нужны и понятны только им и прилепили сверху малоинформативную и путаную часть для обычных пользователей. Может поэтому нумерация каналов в "лоховской" части начинается с единицы а в сервисной "профи" с нуля? Да, программой можно кое-как пользоваться приловчившись, но если вы думаете что она поможет вам при написании своей программы, подскажет код отправки контроллеру и посчитает контрольную сумму, то нет.

Документирована возможность отправки команд через API программы из командной строки. Но... при этом программа должна быть уже запущена и, да, из командной строки команды отправляются. Но когда я попробовал записать последовательность команд (или одну команду) в BAT-файл у меня ничего не получилось. Может быть это я такой криворукий...

Про программу nooLite_ONE и ее недостатки можно написать много, но лучше от этого она не станет и смысла в ее существовании не прибавится, поэтому не буду больше тратить на это время.

Теперь про более старые версии контроллеров (уже сняты с производства).

MТ1132 - 32 канальный, может только отправлять команды системе без обратной связи.

MT-1132

Питание 3 ... 5В, к Arduino подключается напрямую, ничего согласовывать не нужно. Управление модулем осуществляется через стандартный интерфейс UART. Скорость передачи данных - 9600 бит/сек., 8 бит данных, 1 стартовый бит, 1 столовый бит, бит четности - отсутствует. Передача от младшего к старшему биту. Для управления модулем необходимо передать через UART пакет из 12 байт. Описание отправляемых данных есть в техдокументации (не идеальной, но какая есть) к модулю.

МR-1132 - 32 канальный, может только принимать данные от датчиков NooLite.

MR-1132

Чтение документации на модуль MTRF-64 и готовых библиотек навеяло на меня печаль. 64 канала для эксперимента мне не нужны, шифрование и обратная связь тоже, так как силовых блоков NooLiteF у меня нет, буду использовать те что были куплены ранее, без обратной связи, в частности SU-111-200. Поэтому выбор был сделан в пользу MT1132, пусть он уже снят с производства, но он у меня-то он есть в наличии. На том же принципе совсем несложно сделать и управление с шифрованием и обратной связью, было бы желание (просто вместо 12 байт, как для MT1132, отправлять 17 байт на MTRF-64).

Наверно основным плюсом для меня было то что на GitHub обнаружилась библиотека ardunoo для управления MT1132 с помощью Arduino от zhum (Сергей Жуматий), за что ему огромное спасибо! Эта библиотека сводит написание программы управления к нескольким строкам. А умеет библиотека все немало: привязывать и отвязывать силовые блоки, включать и выключать свет, записывать и исполнять сценарии, плавно менять яркость источника света.

В комплекте с библиотекой есть пример скетча с комментариями, который при запуске позволяет выполнять все эти действия вводя буквы в штатный Serial Monitor среды Arduino.

Что ж, определились, будем использовать модуль MT1132. Подключаем Arduino к модулю в соответствии со схемой из документации.

Я использовал контактную макетную плату с набором проводов, это очень ускоряет монтаж. TX модуля подключаем к 10 пину а RX к 11 пину Arduino. Для первых экспериментов взял свой "боевой" китайский клон UNO, уже паленый, с усиленным стабилизатором питания (от него же будет питаться и MT1132), когда все заработало заменил UNO на NANO, его удобно разместить прямо на макетной плате. Для приема команд нам понадобится IR приемник. У меня нашелся TSOP2836, если не ошибаюсь (пробовал и другие, разницы в работе особо не заметил, важно только соблюдать распиновку). Подключаем его в соответствии со схемой включения Vcc к 5В, GND к общему проводу а OUT к 2 пину Arduino.

Берем пример скетча из библиотеки ardunoo и исправляем в ней строку с выбором канала на котором будем работать с силовым блоком, выбираем 8-й канал.

 noo.channel(8);     // Let's command 2-th channel

Запускаем скетч, открываем Serial Monitor и введя в него букву "b" привязываем силовой блок. Теперь можно поиграться, вводя "n" зажигаем свет, "f" - гасим, "x"- меняем состояние и т.п. Убедились что все работет? Идем дальше.

Теперь нам понадобится стандартная библиотека IRremote. которая предназначена для упрощения работы с приёмом и передачей ИК сигналов. С помощью этой библиотеки будем принимать команды с пульта, и выводить их в окно Serial Monitor среды Arduino.

Берем любой IR-пульт (я взял от автомобильного трансмиттера).

Нажимая кнопки, в окне монитора последовательного порта видим соответствующие им коды, расшифрованные arduino. Я не знаю коды всех ли пультов сможет расшифровать библиотека IRremote, но всегда можно что-то подобрать, что по командам не будет пересекаться с устройствами в доме.

Я выбрал три кнопки и решил что одна из них будет включать свет, вторая выключать, а третья - менять состояние.

Вписываем коды выбранных кнопок для вызова функций noo.on(), noo.off() и noo.onoff(). При желании можно дописать другие функции и коды.

Проверяем работу от пульта. Свет включается, выключается и переключается, все как и было задумано. Также сохранилось управление, отправкой буквы в серийный порт (мне это не нужно, но не мешает).

Теперь переходим к управлению с помощью голосового помощника Алиса. Запускаем Яндекс, переходим в раздел устройства.

и выбираем Умный пульт Яндекс (его я установил раньше и планирую использовать и с другими устройствами, имеющими IR-порт). Нажимаем кнопку "Добавить устройство". Выбираем "Настроить вручную".

Вводим название устройства (имеется ввиду наше устройство), я назвал его "На полке". Название устройства нужно выбирать несложное и легкопроизносимое, иначе Алиса будет ошибаться и неправильно распознавать это название, что сделает ввод команд затруднительным.

Дальше производим обучение пульта. Нажимаем "Добавить команду".

Задаем голосовую команду, выбирая из предложенных вариантов или пишем свою. Следуя подсказкам берем пульт.

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

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

Теперь среди устройств появилось "На полке"

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

Также есть вкладка "Голосовые команды" с подсказками.

Проверяем. Подаем команду из подсказки. Работает, задержки почти нет.

Я пока не планирую пока использовать управление системой NooLite через умный пульт Яндекса на постоянной основе, мне было интересно проверить такую возможность, поэтому я не изготавливал печатной платы и не приводил то что у меня получилось к виду законченного изделия. Пока все выглядит вот так.

Но при желании Arduino и модуль МТ1132 можно разместить в пластиковый корпус, прозрачный для инфракрасных лучей. IR-приемник очень чувствительный а Яндекс-пульт посылает мощный сигнал, поэтому располагать пульт и приемник соосно в прямой видимости не понадобится. При необходимости можно будет добавить еще один или несколько IR-приемников подключив их или паралельно или каждый к отдельному пину Arduino. Но пока и так все работает отлично.

Подведу итог: идея работает, все просто и наглядно. Освещением (или любой другой нагрузкой) можно управлять помощью:

1. компьютера через Serial Monitor;

2. пульта от любой бытовой техники;

3. пульта умного дома Яндекс;

4. голосового помощника Алиса на смартфоне, компьютере или колонке.

/*Let you connect MT1132 to your arduino like this:+---------+               +------------+| MT1132  +-(RX)-----(11)-+ Tx Arduino ||         +-(TX)-----(10)-+ Rx         ||         |               |            |*/#include <SoftwareSerial.h>#include <ardunoo.h>#include <IRremote.h>#define RXpin 10#define TXpin 11IRrecv irrecv(2); // указываем вывод, к которому подключен приемникdecode_results results;ArduNoo noo(RXpin,TXpin);void setup(){  Serial.begin(9600);  irrecv.enableIRIn(); // запускаем прием  noo.channel(8);     // Let's command 8-th channel    // ...}void loop(){  int r;  r=Serial.read();  if(r<='9' && r>='0'){ // change channel    noo.channel(r-'0');    return;  }  switch(r){  case 'n': //on    noo.on();    break;  case 'f': //off    noo.off();    break;  case 'x': // toggle    noo.onoff();    break;  case 'c': //print current channel    Serial.print(noo.channel());    break;  case 'b': //bind    noo.bind();    break;  case 'u': //unbind    noo.unbind();    break;  case '+':    noo.slow_on();    break;  case '-':    noo.slow_off();    break;  case '!':    noo.slow_onoff();    break;  case 'r': // record scene!    noo.record_scene();    break;  case 'R': // run scene!    noo.run_scene();    break;  case 's': // toggle 3-rd channel    noo.onoff();    break;  }    if ( irrecv.decode( &results )) { // если данные пришли    Serial.println( results.value ); // печатаем данные в Serial Monitor    if (results.value == 16753245)  //код кнопки, выбранной для выключения   {           noo.off();    //выключаем свет        }    if (results.value == 16769565)  //код кнопки, выбранной для включения   {      noo.on(); //включаем свет           }   if (results.value == 16736925)  //код кнопки, выбранной для изменения состояния      {           noo.onoff();   //меняем текущее состояние света         }    irrecv.resume(); // принимаем следующую команду  }}

Если кому-нибудь понравится - пользуйтесь.