В этом материале я постараюсь рассказать, каким образом можно с телефона или планшета на iOS и Android удалённо управлять вашим самодельным устройством подключенным к сети. Любой, хоть сколь-нибудь знакомый с темой, к этому моменту уже решил, что речь пойдёт об очередном веб-интрефейсе к вашим Arduino и mbed’ам — спешу перебить ваши мысли — не пойдёт. Способ, о котором я хочу рассказать, быстр, дёшев, имеет готовую обратную связь, удобные контролы и обладает наглядностью, которой позавидует самый вылизанный веб-интерфейс.
Чтобы материал не показался оторванным от реальной жизни, я покажу, как мы 4 месяца назад проделали этот фокус с нашим Лайтпаком. Эта ситуация немного отличается от сферического сценария применения протокола Open Sound Control (дальше OSC) в вакууме, но тем не менее, является хорошим примером того, как он может быть эффективно использован в быстром прототипировании.
В наличии мы имели open-source USB-устройтво подсветки, которое управляется кроссплатформенным софтом и имеет на стороне этого софта API для управления из внешних программ или плагинов. Мы хотели управлять этим устройством по сети с наших планшетов и смартфонов. Включать и выключать его, менять профили настроек, управлять яркостью, регулировать подсветку по каждому отдельному каналу и может быть даже запускать другие плагины.
В вашем случае ситуация может быть иной, не осложнённой посредником в виде полноценного ПК и какого-то API. Например, устройство на ARM/AVR периодически подключающееся к сети, или хотя бы Arduino c ethernet-шилдом, который 24/7 логирует для вас потребление электроэнергии за щитком в подъезде и шлёт данные прямиком в гуглодокумент.
Первое, что приходит в голову для решения такой задачи — веб-интерфейс. Казалось бы универсально: можно получить доступ с любой платформы. Но заставлять постоянно крутиться веб-сервер, каким бы микроскопическим он ни был, нам не хотелось. Да и хороших конструкторов веб-интерфейсов, которые бы имели подходящие нам контролы, мы сходу не нашли, рисовать свои не хотели и понимали, что результат всерьёз сможет работать лишь на десктопе и рядовой МК его не осилит в случае если в будущем нам придётся управлять standalone-устройством.
Однако, если к устройству можно подключиться через сеть (в нашем случае слать команды в API можно прямо через Telnet) можно было бы написать полноценное приложение для мобильной платформы, которое бы просто слало пакеты-сообщения, а сервер парсил их и таким образом управлял бы устройством. Не смотря на то, что мы за вечер собрали небольшой прототип для Android, который эксплуатировал этот способ, он всё-равно оставался “дорогим” даже в сравнении с веб-интерфесом.
Время шло, задача записалась где-то на подкорке и не вылезала оттуда до тех пор, пока я случайно не наткнулся на мобильное приложение TouchOSC, которое (практически) одинаково хорошо работает на iOS и Android.
После демонстрационных роликов и скриншотов пройти мимо не попробовав было попросту невозможно.)
Если коротко, то приложение TouchOSC (AppStore, Google Play) реализует на ваших мобильных девайсах интерфейсы протоколов OSC и MIDI, с которыми привыкли работать все специализированные синтезаторы, редакторы звука, программы для диджеев, студий звукозаписи и пр. При этом TouchOSC даёт возможность использовать не только предустановленные раскладки контролов (layouts) кнопок-слайдеров-ярлычков, но и очень просто и быстро рисовать свои собственные в специальном редакторе. Всё это добро работает через wi-fi, но может работать и по проводам при наличии специальных адаптеров.
Типичная раскладка из состава предустановленных выглядит примерно так. Уровень сложности: «Корейцы», что, впрочем не мешает вам повторить её в редакторе раскладок.
Поверхностный анализ показал, что это приложение не единственное и по желанию для iOS можно воспользоваться iOSC, OSCemote, Mrmr OSC controller, Remokon for OSC (для Android даже перечислять не буду — их ещё больше). Этот же анализ показал, что сам протокол используется в большом числе программ и устройств, а самое главное для нас то, что библиотеки и обёртки с его реализацией существуют для многих языков программирования и платформ (вот, например, варианты для Arduino и mbed). Неполный список есть на официальном сайте.
У нас появилась возможность нетипичным образом применить новый, интересный, на первый взгляд, инструментарий. Впереди был свободный выходной день, поэтому со словами “вызов приянт” timsat на одну половину монитора развернул Гугл, а на вторую Notepad++.
Open Sound Control — это пакетный протокол передачи данных между мультимедийными устройствами (в первую очередь электронными музыкальными инструментами/ синтезаторами и ПК), который в последнее время всё чаше используется как замена MIDI. Основновной фичей протокола остаётся работа через сеть, но есть и другие особенности. Последняя версия спецификации доступна на сайте Центра Аудио-технологий университета Беркли (CNMAT).
Как я уже упоминал, на сегодняшний день типичное применение протокола — обеспечение интерфейса между устройствами ввода (синтезаторами, планшетами, игровыми контроллерами и пр.) и специализированными программами такими, как Super Collider, Traktor, REAPER и пр. OSC “из коробки” поддерживается такими потрясающими устройствами, как Lemur и Monome.
Работая по сети протокол позволяет обмениваться данными в обоих направлениях, что позволяет реализовать обратную связь с устройством. Если приглядеться к скриншотам, то некоторые контролы-кнопки имеют дополнительный индикатор, который можно зажечь после того, как посланная ранее команда была исполнена сервером в реальности. Т.е. ваш планшет может отражать реальное состояние устройства, которым вы управляете (целевого). Если наловчиться, можно даже графики рисовать, но это для мусьё, которые знают толк в извращениях.
Вот пример сообщений, которыми обмениваются OSC-сервер и клиент:
В данном случае у нас имеется точный идентификатор контрола и /1/fader2 0.497120916843 означает, что со второго ползунка на первой вкладке (да, там можно использовать несколько вкладок в пределах одного лэйаута) к серверу приехало значение 0.49 и т.д. Z-message из этого примера можно включить по желанию и о нём я расскажу позже.
В примере с Лайтпаком нам было удобно пересылать на планшет названия профилей и переключаться между ними. Кроме этого, при старте сессии положения всех контролов на планшете автоматически выравниваются по реальным настройкам целевого устройства.
Для работы с API Лайтпака мы используем собственную обёртку написанную на Python. Поэтому, а ещё потому, что для Питона существовала удовлетворяющая нас OSC-библиотека, мы решили написать небольшой скриптик, который фаткически являлся коннектором между API и сетевым устройством посылающим OSC-сообщения. Главные требования для такой реализации:
Хотя, если поковыряться с тунелями на вашем роутере, то второе ограничение можно обойти и управлять поилкой для вашего хомячка из офиса на другом конце города.
Для тех, кто, как и я, предпочитает картинки, наколхозил схему взаимодействия:
В нашем случае обмен между коннектором и API реализован через сокеты (это фича самого API), при этом, как видно в демо всё работает довольно быстро. Разумеется, в уравнении с хомяком на Ардуино, прямо за роутером будет находится само устройство с центром логики в виде микроконтроллера с прошивкой в которую уже включены библиотеки для работы с сетью и OSC.
Фактически для реализации, нам предстояло разобраться лишь с процессом инициализации обмена, обратной связью и преобразованием получаемых/передаваемых значений. Львиную долю кода занимает простой маппинг. Т.е. после того, как вы нарисуете лэйаут у вас на руках будет список адресов контролов (кнопочек, слайдеров, ярлычков и пр), каждый из которых нужно сопоставить с функцией API. Всё.
Честно говоря, не знаю, о чём тут можно написать подробнее. С точки зрения программирования задача примитивна. Исходный код этого “коннектора” по обыкновению лежит у нас в репозитории и доступен для всех.
Кстати, в TouchOSC реализованы некоторые довольно удобные дополнительные фичи: Во-первых, есть возможность использовать сообщение /ping которым обмениваются клиент с сервером для поддержки соединения даже когда сами данные не бегают. Во-вторых, поддерживается так называемый z-message — специальное сообщение, которое говорит серверу, что пользователь на клиенте наконец-то закончил возюкать пальцем по экрану (момент окончания ввода). Мы не использовали эту фичу, но не исключаю, что существуют ситуации в которых она окажется крайне полезной. В-третьих, как и большинство похожих приложений, TouchOSC умеет слать на сервер даные со встроенного в мобильный девайс акселерометра. Т.е. вы можете использовать свой смартфон или планшет как хитрое устройство ввода для ваших сетевых самоделок (крутить камерой на сервомашинках и пр.).
Всё, что касается взаимодействия с приложением TouchOSC проходит гладко. Даже загрузка собственных лэйаутов осуществляется “по воздуху” нажатием одной кнопки. Единственный на сегодняшний день заметный недостаток — это невозможность загрузки собственных лэйаутов для версии под Android. В переписке с автором ему удалось убедить меня в том, что “уже вот-вот, готовлю к релизу”.
Библиотека для Питона оказалась не очень хорошо документирована, поэтому мы дольше инициализировали процесс обмена данными, чем реально программировали поведение лэйаута.
В целом, процесс создания такого машапа предельно интуитивен и не займёт много времени. Вот почему я бы посоветовал использовать OSC для быстрого прототипирования вместо полноценных клиент-серверных стеков с веб-интерфейсами. Тем более, если вы собираетесь презентовать этот прототип на мероприятии, или, скажем, заказчику, более наглядного варианта реализации сопровождающегося вау!-как-у-вас-такое-пропустили-в-эппстор вопросами я попросту не знаю.
Итак, ещё раз: Если вам необходимо быстро и дёшево реализовать простой способ наглядного управления самодельным сетевым устройством с обратной связью, то протокол OSC — интересный выбор.
Чтобы материал не показался оторванным от реальной жизни, я покажу, как мы 4 месяца назад проделали этот фокус с нашим Лайтпаком. Эта ситуация немного отличается от сферического сценария применения протокола Open Sound Control (дальше OSC) в вакууме, но тем не менее, является хорошим примером того, как он может быть эффективно использован в быстром прототипировании.
Задача
В наличии мы имели open-source USB-устройтво подсветки, которое управляется кроссплатформенным софтом и имеет на стороне этого софта API для управления из внешних программ или плагинов. Мы хотели управлять этим устройством по сети с наших планшетов и смартфонов. Включать и выключать его, менять профили настроек, управлять яркостью, регулировать подсветку по каждому отдельному каналу и может быть даже запускать другие плагины.
В вашем случае ситуация может быть иной, не осложнённой посредником в виде полноценного ПК и какого-то API. Например, устройство на ARM/AVR периодически подключающееся к сети, или хотя бы Arduino c ethernet-шилдом, который 24/7 логирует для вас потребление электроэнергии за щитком в подъезде и шлёт данные прямиком в гуглодокумент.
Первое, что приходит в голову для решения такой задачи — веб-интерфейс. Казалось бы универсально: можно получить доступ с любой платформы. Но заставлять постоянно крутиться веб-сервер, каким бы микроскопическим он ни был, нам не хотелось. Да и хороших конструкторов веб-интерфейсов, которые бы имели подходящие нам контролы, мы сходу не нашли, рисовать свои не хотели и понимали, что результат всерьёз сможет работать лишь на десктопе и рядовой МК его не осилит в случае если в будущем нам придётся управлять standalone-устройством.
Однако, если к устройству можно подключиться через сеть (в нашем случае слать команды в API можно прямо через Telnet) можно было бы написать полноценное приложение для мобильной платформы, которое бы просто слало пакеты-сообщения, а сервер парсил их и таким образом управлял бы устройством. Не смотря на то, что мы за вечер собрали небольшой прототип для Android, который эксплуатировал этот способ, он всё-равно оставался “дорогим” даже в сравнении с веб-интерфесом.
Время шло, задача записалась где-то на подкорке и не вылезала оттуда до тех пор, пока я случайно не наткнулся на мобильное приложение TouchOSC, которое (практически) одинаково хорошо работает на iOS и Android.
После демонстрационных роликов и скриншотов пройти мимо не попробовав было попросту невозможно.)
Идея
Если коротко, то приложение TouchOSC (AppStore, Google Play) реализует на ваших мобильных девайсах интерфейсы протоколов OSC и MIDI, с которыми привыкли работать все специализированные синтезаторы, редакторы звука, программы для диджеев, студий звукозаписи и пр. При этом TouchOSC даёт возможность использовать не только предустановленные раскладки контролов (layouts) кнопок-слайдеров-ярлычков, но и очень просто и быстро рисовать свои собственные в специальном редакторе. Всё это добро работает через wi-fi, но может работать и по проводам при наличии специальных адаптеров.
Типичная раскладка из состава предустановленных выглядит примерно так. Уровень сложности: «Корейцы», что, впрочем не мешает вам повторить её в редакторе раскладок.
Поверхностный анализ показал, что это приложение не единственное и по желанию для iOS можно воспользоваться iOSC, OSCemote, Mrmr OSC controller, Remokon for OSC (для Android даже перечислять не буду — их ещё больше). Этот же анализ показал, что сам протокол используется в большом числе программ и устройств, а самое главное для нас то, что библиотеки и обёртки с его реализацией существуют для многих языков программирования и платформ (вот, например, варианты для Arduino и mbed). Неполный список есть на официальном сайте.
У нас появилась возможность нетипичным образом применить новый, интересный, на первый взгляд, инструментарий. Впереди был свободный выходной день, поэтому со словами “вызов приянт” timsat на одну половину монитора развернул Гугл, а на вторую Notepad++.
Протокол
Open Sound Control — это пакетный протокол передачи данных между мультимедийными устройствами (в первую очередь электронными музыкальными инструментами/ синтезаторами и ПК), который в последнее время всё чаше используется как замена MIDI. Основновной фичей протокола остаётся работа через сеть, но есть и другие особенности. Последняя версия спецификации доступна на сайте Центра Аудио-технологий университета Беркли (CNMAT).
Как я уже упоминал, на сегодняшний день типичное применение протокола — обеспечение интерфейса между устройствами ввода (синтезаторами, планшетами, игровыми контроллерами и пр.) и специализированными программами такими, как Super Collider, Traktor, REAPER и пр. OSC “из коробки” поддерживается такими потрясающими устройствами, как Lemur и Monome.
Работая по сети протокол позволяет обмениваться данными в обоих направлениях, что позволяет реализовать обратную связь с устройством. Если приглядеться к скриншотам, то некоторые контролы-кнопки имеют дополнительный индикатор, который можно зажечь после того, как посланная ранее команда была исполнена сервером в реальности. Т.е. ваш планшет может отражать реальное состояние устройства, которым вы управляете (целевого). Если наловчиться, можно даже графики рисовать, но это для мусьё, которые знают толк в извращениях.
Вот пример сообщений, которыми обмениваются OSC-сервер и клиент:
/1/fader2 0.497120916843
/1/fader2 /z
/1/rotary1 0.579584240913
/1/rotary1 0.605171322823
/1/rotary1 /zВ данном случае у нас имеется точный идентификатор контрола и /1/fader2 0.497120916843 означает, что со второго ползунка на первой вкладке (да, там можно использовать несколько вкладок в пределах одного лэйаута) к серверу приехало значение 0.49 и т.д. Z-message из этого примера можно включить по желанию и о нём я расскажу позже.
В примере с Лайтпаком нам было удобно пересылать на планшет названия профилей и переключаться между ними. Кроме этого, при старте сессии положения всех контролов на планшете автоматически выравниваются по реальным настройкам целевого устройства.
Реализация
Для работы с API Лайтпака мы используем собственную обёртку написанную на Python. Поэтому, а ещё потому, что для Питона существовала удовлетворяющая нас OSC-библиотека, мы решили написать небольшой скриптик, который фаткически являлся коннектором между API и сетевым устройством посылающим OSC-сообщения. Главные требования для такой реализации:
- Доступность портов клиента/сервера (в TouchOSC можно настроить свои)
- Клиент и сервер должны находиться в одной сети.
Хотя, если поковыряться с тунелями на вашем роутере, то второе ограничение можно обойти и управлять поилкой для вашего хомячка из офиса на другом конце города.
Для тех, кто, как и я, предпочитает картинки, наколхозил схему взаимодействия:
В нашем случае обмен между коннектором и API реализован через сокеты (это фича самого API), при этом, как видно в демо всё работает довольно быстро. Разумеется, в уравнении с хомяком на Ардуино, прямо за роутером будет находится само устройство с центром логики в виде микроконтроллера с прошивкой в которую уже включены библиотеки для работы с сетью и OSC.
Фактически для реализации, нам предстояло разобраться лишь с процессом инициализации обмена, обратной связью и преобразованием получаемых/передаваемых значений. Львиную долю кода занимает простой маппинг. Т.е. после того, как вы нарисуете лэйаут у вас на руках будет список адресов контролов (кнопочек, слайдеров, ярлычков и пр), каждый из которых нужно сопоставить с функцией API. Всё.
Честно говоря, не знаю, о чём тут можно написать подробнее. С точки зрения программирования задача примитивна. Исходный код этого “коннектора” по обыкновению лежит у нас в репозитории и доступен для всех.
Кстати, в TouchOSC реализованы некоторые довольно удобные дополнительные фичи: Во-первых, есть возможность использовать сообщение /ping которым обмениваются клиент с сервером для поддержки соединения даже когда сами данные не бегают. Во-вторых, поддерживается так называемый z-message — специальное сообщение, которое говорит серверу, что пользователь на клиенте наконец-то закончил возюкать пальцем по экрану (момент окончания ввода). Мы не использовали эту фичу, но не исключаю, что существуют ситуации в которых она окажется крайне полезной. В-третьих, как и большинство похожих приложений, TouchOSC умеет слать на сервер даные со встроенного в мобильный девайс акселерометра. Т.е. вы можете использовать свой смартфон или планшет как хитрое устройство ввода для ваших сетевых самоделок (крутить камерой на сервомашинках и пр.).
Подводные камни
Всё, что касается взаимодействия с приложением TouchOSC проходит гладко. Даже загрузка собственных лэйаутов осуществляется “по воздуху” нажатием одной кнопки. Единственный на сегодняшний день заметный недостаток — это невозможность загрузки собственных лэйаутов для версии под Android. В переписке с автором ему удалось убедить меня в том, что “уже вот-вот, готовлю к релизу”.
Библиотека для Питона оказалась не очень хорошо документирована, поэтому мы дольше инициализировали процесс обмена данными, чем реально программировали поведение лэйаута.
В целом, процесс создания такого машапа предельно интуитивен и не займёт много времени. Вот почему я бы посоветовал использовать OSC для быстрого прототипирования вместо полноценных клиент-серверных стеков с веб-интерфейсами. Тем более, если вы собираетесь презентовать этот прототип на мероприятии, или, скажем, заказчику, более наглядного варианта реализации сопровождающегося вау!-как-у-вас-такое-пропустили-в-эппстор вопросами я попросту не знаю.
Итак, ещё раз: Если вам необходимо быстро и дёшево реализовать простой способ наглядного управления самодельным сетевым устройством с обратной связью, то протокол OSC — интересный выбор.
