Что-то никак я не отойду от этой темы. Но у Алексея появилась прекрасная идея. Сейчас для дистанционного управления нашим роботом требуется Windows-клиент. Да, он не сложный и его содержимое можно портировать на любые ОС, включая мобильные. Но Алексей предложил использовать в качестве клиента браузер. Если получится, то погонять своим роботом по квартире можно будет с любого компьютера и из любой точки, где есть интернет. Давно хотел, чтобы друзья могли виртуально сходить ко мне в гости.
Трансляция видео и аудио у нас сейчас выполняются посредством Android-приложения IPWebcam, а оно и предполагает воспроизведение в браузере. Эта часть работает, я проверял. Правда, воспроизведение звука кэшируется браузером и есть очень существенное отставание. Но наверняка это можно побороть. Остаётся передача команд роботу. Управление, по возможности, оставить бы прежним. Где это невозможно, обсудим и приведём к общему знаменателю.
Прелесть задачи в том, что робот пока не нужен. Достаточно Android-смартфона с нашим приложением. На первом этапе можно поработать с командами, выполняющимися на уровне смартфона: смена мордочек, например. А позже хорошо бы сделать какой-то эмулятор для тестов. Ну и могу предоставить Митю для опытов.
Есть желающие взяться за такую задачку?
Можно попробывать заюзать Google Cloud Messaging.
ОтветитьУдалитьНо есть сомнения по поводу скорости работы и возможности использования для других платформ сего чуда. Посему, другое решение -- использование web-сокетов.
У меня нет опыта применения ни одного, ни другого решения. Google Cloud Messaging у меня тоже вызывает сомнения, как я понимаю, соединение будет уже не точка-точка. А web-сокет, кажется, построен на базе tcp-сокета. Tcp-сокет у Мити раньше был, и я от него отказался в пользу udp. Даже в пределах локальной сети при ухудшении сигнала wifi на tcp-сокете были задержки до 5 секунд. Udp датаграммы сейчас с этим справляются на ура. Дело в том, что положения джойстиков передаются постоянно, и потеря нескольких пакетов незаметна. А tcp подобных вольностей не прощает.
ОтветитьУдалитьRFC-6455 говорит, что web-сокет не обязательно по TCP.
ОтветитьУдалить5 сек. это много конечно, но я не вижу другого адекватного и максимально независимого от платформы решения.
Как вариант можно пооптимизировать протокол.
Можно конечно посмотреть в сторону флэша и java-апплетов.
Основной плюс -- возможность установления прямого соединения
Основной минус -- страдает мультиплатформенность.
(Есть ли другие +/-?)
Нет, в п.1.7 сказано: "The WebSocket Protocol is an independent TCP-based protocol". Вдумчиво этот стандарт не читал, но "UDP" в этом документе не встречается.
УдалитьА вообще странно, я уверен должны быть способы отправлять UDP-датаграммы из браузера. Передача динамичного управления по TCP-сокету это утопия. Ведь 5 секунд, это возможная задержка в локальной сети, когда мой роутер непонятно чем занимался. А что будет в глобальной? Все быстрые игры используют UDP, а у нас тут вообще момент ответственный - пока TCP-сокет пыжится сдержать слово и передать пакет "стой!", робот уже убьёт себя об стену, или сбросится со стола. А вы будете наблюдать за этим на видео, там ведь UDP на низах.
Если HTML5 настойчиво пытается захоронить Flash, может он может предложить что-нибудь взамен? Я тут совсем не специалист.
Примеры использования websocketов внушают уверенность в том, что это уже вполне юзабельно :)
Удалитьраз -- чтобы увидеть эффект надо открыть два окна(можно и на телефоне))
два
три
Интересно. Я посмотрел третий пример. Задержка максимум 1/2 секунды - вполне сносно. Всегда ли так? Надо разбираться, наверняка придётся переделывать Android-часть, а там для совместимости и Windows. Я пока пас – озадачен будущим сайтом и сенсорами ориентации телефона.
УдалитьПо мне так третий самый тормозной из них:)
УдалитьЯ правильно понимаю что:
1. Состояние джойстика посылается постоянно?
2. Схема работы примерно такая
PC <--WiFi--> Android <--Bleutooth--> Arduino
3. Причем, когда только передаются команды данные передаются только в одну сторону
PC --WiFi--> Android --Bleutooth--> Arduino
Дмитрий, Вы можете собрать некоторую статистику(лог) по работе программы? (в csv)
Такие как:
- количество отправленных с ЦУПа пакетов в секунду
- количество полученных на Андройдофон пакетов в секунду
- количество отправленных с Андройдофона пакетов в секунду
- количество полученных на Arduino пакетов в секунду
Для чистоты эксперимента хотелось бы чтобы в это время медиа данные не передавались. А еще лучше если будут логи без медия и с медиа.
1. Да постоянно. Точнее, только состояния двух джойстиков геймпэда.
Удалить2. Да.
3. Участок ПК - Android да, но скоро будет передача в оба конца. Участок Android - Arduino в оба конца.
Залим, по статистике не имею ни малейшего представления как это сделать.
Вряд ли вас интересует участок с Bluetooth. Но могу точно сказать, что там обмен редкий. Команды передаются только новые (отличающиеся от предыдущих того же типа). Т.е. повторяющихся команд для моторов и серв нет. Обратно идут ошибки, команды РобоСкрипта уровня телефона и сигналы от ИК сенсора (сейчас снятого - эхо робобитв). Всё это экзотика.
На линии WiFi картина такая. Сейчас команды управления движением и ориентацией головы (4 команды по 7 байт) идут с минимальным интервалом 20 мСек. Каждая команда отправляется отдельным пакетом. Остальные команды посылаются редко, разово, по факту изменения состояния кнопок.
На всякий случай... Ранее встреченные мной 5-ти секундные задержки при использовании TCP-сокета, не были связаны с перегрузкой канала управления роботом. Тогда повторяющиеся команды управления движением и головы роботу не посылались. Повторяться они стали только с переходом на более быстрый но ненадёжный канал UDP.
Да, меня интересовала/интересует загруженность канала. Ну и задержка в 5 сек, показалось странным, очень. Тем более, если обмен идет в пределах одной сети.
Удалить