Архитектура ПО для носимого компьютера

А поподробнее про этот пульт можно? В плане, что именно он, абстрактно говоря, из себя представляет? Некоторое количество кнопок? COM-терминал? Джойстик?

Иными словами, если задаться спаять такой без нокии внутри, что нужно? кнопки? экран?

Нынешняя версия пульта - это N900 с экранными кнопками на сенсорном дисплее, позволяющими переключать режимы, скроллить/зумить карту и пр. Не то, что мне хотелось - но вполне юзабельно, да и позволило отладить связь по bluetooth.

Более правильными вариантами мне представляются 2 следующих:
1) на базе недорогого qwerty-телефона с bluetooth/j2me - например, Alcatel OT-800 (чтобы можно было работать с текстами на НК)
2) простое устройство с мини-джойстиком, несколькими кнопками и чем-нибудь для плавного скроллинга (миниатюрный тачпад, трекбол, лазерный блок от мыши). Проще всего, видимо, реализовать что-то подобное на базе синезубой мыши.

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



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

То есть по сути этот "беспроводной пульт" - это просто штука с несколькими кнопками. Так?
В частности, видео с компьютера он не получает. Так?

фото давай )

Скриншот с пульта - вот:
http://ru-wearable.livejournal.com/99923.html?thread=1071187#t1071187
Скриншот приложения (карта отмасштабирована так, чтобы названия читались на наголовнике 320*240). Но вообще нужно переходить с растровых Google Maps на векторные OSM.

Неплохо,потом сырцы и все остальное покажешь? Я все же намерен PDA допилить )

Сделала фото, после праздников выложу статью на Хабр. Числа 12-го, наверное, будет оптимально. Новый юзерпик - побочный эффект сегодняшней фотосессии :)

Странно, юзерпик почему-то не меняется...

буду ждать

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

С камерой давно не работала, сейчас лень подключать. Но лаг был заметный - порядка полусекунды. Или четвертьсекунды. Для прототипа - допустимо. А в релизной версии устройства, думаю, устранить лаг будет не проблема - это же внешняя камера, подключающаяся к N900 по USB, если бы использовалась родная камера телефона, лага бы практически не было. Так что когда вместо телефона будет какой-нибудь IGEP или Rapsberry, с правильной камерой, укрепленный на очках - все должно работать гораздо лучше :)

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

Я бы очень просил описать, что именно твоё приложение делает сейчас или что ты хотела бы, чтобы оно делало.

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

Попробую описать.

Носимый компьютер - это вычислительное устройство, способное обрабатывать данные окружающего мира (GPS, аудио/видеопотоки и т.п.), данные пользователя (направление взгляда, пульс и др.). Вывод с носимого компьютера по возможности интегрируется в воспр иятие пользователем окружающего мира - в виде аудиосигналов, визуальных объектов (как "встроенных" в изображение реального мира, так и просто выводимых на наголовный дисплей) - чтобы пользователь мог воспринимать поступающую с НК информацию, минимально переключая внимание с окружающего мира на девайс. Еще одеа цель AR-объектов - дополнять реальные объекты неявной информацией (например, дополнять встреченного пользрвателем человека плашкой с ФИО встреченного, информацией о предыдущих встречах и т.п.)

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

Сейчас у меня есть законченный вариант прототипа "железного" решения для НК. Но чтобы он стал реально работающим прототипом носимого компьютера, нужен соответствующий софт. Причем желательно, чтолбы софт сразу решал бы какую-то прикладную (и, желательно, необходимую разработчику) задачу. В качестве первого use case я выбрала GPS-навигатор для пешего и велосипедного применения. Сейчас навигатор находится во вполне функциональном состоянии - я его активно использую по прямому назначению. Теперь нужно дописывать другие функции - работу с камерой, AR и пр.

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

НК для вело-навигационных задач:
- модуль для вывода на наголовник Eyetop Centra
- модуль для чтения данных с беспроводного пульта с мини-джойстиком
- модуль для работы с внешней наголовной камерой (для использрвания ее в качестве зеркала заднего вида)
- модуль GPS-навигации
- модуль работы с картами Google Maps
- модуль вывода картинки с камеры в качестве зеркала заднего вида
- GUI для беспроводного пульта с мини-джойстиком

НК для приложения дополненной реальности
- модуль для вывода на вузиксовский see-through наголовник
- модуль для чтения данных с пульта на базе телефона с bt/j2me
- модуль для работы с внешней наголовной камерой
- модуль GPS-навигации
- модуль для работы с наголовным компасом
- модуль анализа картинки с камеры и наложения на него AR-объектов
- модуль логики приложения
- GUI для беспроводного пульта на базе телефона

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

В общем, сейчас я хочу создать надстройку над Maemo - как в свое время это сделала M$, выпустив M$Win 3.11. Ну а в дальнейшем логичнее будет перенести данный механизм на уровень ОС - возможно, отказавшись от Maemo и перейдя, к примеру, на "Фантом" Дмитрия Завалишина.

Прошу прощения за сумбурность изложения - опаздываю, надо ехать :(

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

P.S. Кудайта это ты в празднично-каникульный день намылилась? Сидеть надо дома, код писать :)

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

В начале тут должно идти вступление, мол НК отличается от традиционной персоналки и потому...но что-то это вступление у меня никак не придумывается толком. Потому отмечу три вещи:

* у НК может быть и скорее всего будет несколько "экранов". Ну элементарно: левый глаз, правый глаз, экранчик на запястье или в кармане (на случай показать кому-нибудь телефонный номер, карту, фотку и т.п.)

* у НК может быть и скорее всего будет несколько источников аудиосигнала (внешний микрофон, микрофон гарнитуры, телефон, радиоприёмник, системные звуки и плеер-диктофон) и несколько "получателей" аудиосигнала (наушники, внешний динамик, телефон, диктофон опять же)

* НК, вероятнее всего, будет иметь достаточно нестандартную периферию и в частности - датчики: GPS, пульсомер, датчик освещённости, пульт-джойстик, блок инерциальной навигации, компас...

Представляется, что "ядро" НК должно обеспечивать для отдельных компонентов НК-софта:

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

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

* организацию стандартного доступа к информации с именованных датчиков и предоставления этой информации. Опять примеры:
1) Я хочу послать в систему запрос "который час" и получить стандартный timestamp. При этом меня не волнует, как именно реализованы часы. Они могут быть реализованы просто внутренним таймером. Они могут быть реализованы внутренним таймером с периодической "подводкой" через NTP, а в отсутствие сети - через GPS. Наконец, внутренний таймер может вообще не использоваться, а время может непосредственно сниматься с GPS-чипа.
2) Я хочу послать "в систему" запрос "что сейчас видит камера" и получить картинку. И не морочиться - в клиентском приложении - с инициализацией и поиском видеоустройств и тому подобной шнягой. Тем более что "что сейчас видит камера" может быть, строго говоря, не просто картинкой непосредственно с камеры, а результатом некоей обработки специальным модулем.
3) Я хочу послать в систему запрос "где я" и получить координаты. При этом я не хочу мучиться с парсингом NMEA-сообщений в клиентском приложении. Более того, эти координаты ведь могут получаться не просто напрямую с GPS - может быть дополнительный модуль, который агрегирует информацию с GPS, с GSM-модуля и с модуля инерциальной навигации и пытается выдать максимально точные координатфы в том числе в условиях недоступности GPS-сигнала.

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

* организацию оповещений о наступлении тех или иных событий. Ну довольно стандартный механизм - регистрируешь обработчик для события с таким-то именем, и в случае его наступления обработчик что-то делает. Примеры:
1) Сигнал о критическом разряде батареи может вызвать сразу много событий. Отключение энергозатратных функций (GPS, радиосвязь), уменьшение или ликвидацию буферов в оперативке со сбросом данных на диск, отображение предупреждения на экране и т.п. При этом "оповещатель" может быть настроен на разный уровень заряда как на критический с одной стороны, а с другой - что именно произойдёт при отправке такого оповещения "оповещатель" не интересует, это определяется другими модулями, которые зарегистрировались для получения этого оповещения.
2) Модуль выделения лиц получает видеопоток с камеры, пытается выделить на нём лица, пробежаться по базе и найти знакомых. Если это удалось, он отправляет оповещение "в кадре Петя". Другой модуль может перехватывать это оповещение, отыскивать в планировщике последние связанные с петей задачи и выводить их на экран интерфейса. Если среди них есть срочные, этот модуль может отправить сообщение "Внимание оператору", которое перехватит уже третий модуль и проиграет мелодию или сделает вибровызов или ещё что-то в таком роде.
3) Отправка сигнала "ТИХО!" может привести к отключению всех внешних источников звуков и ограничению кромкости в наушниках до минимальной.

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

В функции самой программы-ядра, вероятно, входит запуск всех модулей и соединение их по некоему "графу передачи информации", который у этого менеджера где-то лежит в файле. Вероятно, нужен также некий язык описания этого графа, вроде UML, и инструменты для визуального построения этих диаграмм. Но вот его можно и попозже разработать :)

Ну и наконец: мне представляется, что это строить надо на основе GStreamer'а (для организации аудио-видеопотоков) и D-Bus'а (для доступа к данным и организации оповещений). Тем более они уже есть и хорошо документированы. QPlugin и "плагины на Си" имеет смысл использовать уже для отдельных компонентов. Которые, в свою очередь, тоже вполне могут быть модульными.

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

===================================

В качестве простейшего примера для демонстрации концепции можно было бы сделать простейшее - но модульное! - приложение. Оно должно выдавать на наголовник картинку с камеры если ты идешь (двигаешься со скоростью выше определенной) и карту с твоим положением - если ты стоишь.

Не то чтобы от такого приложения сильно много пользы, но оно демонстрирует взаимодействие всех основных компонентов:
1) есть модуль, публикующий данные о текущем местоположении и скорости
2) есть другой модуль, периодически опрашивающий первый модуль, и если скорость поднялась выше определенной или опустилась ниже определенной - генерирующий оповещение "я пошёл"/"я остановился"
3) есть видеопоток с камеры
4) придуман способ, как направить GUI-интерфейс тоже в видеопоток, а не напрямую отрисовывать на экране рабочий стол
5) на наголовник выводится именно видеопоток, а не интерфейс отрисовывается напрямую движком рабочего стола
6) есть модуль-переключатель, который перехватывает сообщения "я пошёл"/"я остановился", и соответственно переключает видеопотоки
7) в идеале картографическое приложение должно брать информацию о положении через всё ту же шину, из модуля (1)

Это НЕ ОПТИМАЛЬНЫЙ способ - в частности, периодическое опрашивание чего-либо желательно по возможности исключать и уж тем более - если опрос производится через эту нашу системную шину данных. По возможности надо делать систему, то что называется, event-driven. В конце-концов, это сэкономит электричество :) Но именно как демонстрация - очень даже.

P.S. Уточню - в наголовнике просто показывается либо картинка с камеры, либо картинка с рабочего стола. Картографическое приложение запустить можно и ручками...ну или кроном или ещё чем

P.P.S. Тут ещё много чего можно дополнить - дъявол, он ведь в деталях. Но это имеет смысл в том случае, если я вообще пытаюсь ответить на тот вопрос, который поставлен, а не на тот, который я сам себе придумал :) Так что желательно уточнить - это ВООБЩЕ примерно то, что хотелось услышать или нет?

Пульты:
http://www.metawatch.org/models/
http://www.wimm.com/
http://www.imwatch.it/ru-en/

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

WBR,
Sergey.

Спасибо за ссылки! Девайсы любопытные, надо будет присмотреться :)

http://www.reconinstruments.com/developer

MOD == micro optics display.

Продается в США и Европе без проблем.

MOD Live Platform

CPU: Cortex A8, 600Mhz
Operating System: Android 2.3.4
Screen Resolution 428 x 240, landscape mode
Connectivity: Bluetooth 4.0
Input device: 6-button Bluetooth Remote Control
Sensors:
3-axis accelerometer
3-axis gyro
3-axis magnetometer
Barometer
Temperature sensor on remote control
Android Features Available on MOD Live

Application model - Activity and Service
2D graphics - up to 30fps, but normally updated at 1fps for optimal battery life
Bluetooth Sockets
Sensor manager
SQLite databases and application persistent data
Access to up to 100Mb of mass storage shared between all apps
App Development Process

Download Android SDK at http://developer.android.com
Register as MOD Live app developer
Obtain MOD Live SDK library (.jar files) and documentation from Recon
Develop app using Android SDK and link to MOD Live Library
Make sure that app uses only supported hardware components
Use adb to test app on MOD Live
Submit app to Recon for distribution
Key Features of MOD Live SDK Library

MOD Service:
Register for location, speed and altitude data
Register for skiing/snowboard stats such as runs, jumps, vertical and distance
Sensor Framework Extension:
Synchronised (once-per-second) sensor polling
Free fall detection event
Gravity, linear acceleration and rotation vector (future)

Списывалась некоторое время назад с разработчиками - еще по поводу предыдущей модели. Железка любопытная - но удастся ли влегкую прикрутить к ней, например, камеру? Если смотреть демо-ролик, похоже, что да. Но по описанию технических характеристик - камеры в системе нет. Нагуглить, есть ли камеры, подключающиеся по Bluetooth 4.0, мне пока не удалось.

Я представляю архитектуру так:

1 Это программа с минимальным набором функций
- 1 Вывод видео не важно куда.
- 2 Вывод звук не важно куда.
- 3 Модуль GPS\ГЛОНАСС и т.д. (кто что припилит)
- 4 Какая-нибудь система управления(пульт\кпк\смартфон\голос и т.д. нужно будет определиться)
2 Это удобный интерфейс для модулей\плагинов (тот же QPlagin)

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

Модули - это железка + плагин
Например микрофон + распознавания голосовых комманд

Плагин - это софт который управляет железкой\ или же просто скрипт для удобства пользователя.

Это самая верхняя абстракция архитектуры..

Если это интересная архитектура могу расписать(на блок схемах) и нижние слои абстракции =)