воскресенье, 7 октября 2012 г.

И снова о дистанционном управлении

Дистанционное управление
Что-то никак я не отойду от этой темы. Но у Алексея появилась прекрасная идея. Сейчас для дистанционного управления нашим роботом требуется Windows-клиент. Да, он не сложный и его содержимое можно портировать на любые ОС, включая мобильные. Но Алексей предложил использовать в качестве клиента браузер. Если получится, то погонять своим  роботом по квартире можно будет с любого компьютера и из любой точки, где есть интернет. Давно хотел, чтобы друзья могли виртуально сходить ко мне в гости.

Трансляция видео и аудио у нас сейчас выполняются посредством Android-приложения  IPWebcam, а оно и предполагает воспроизведение в браузере. Эта часть работает, я проверял. Правда, воспроизведение звука кэшируется браузером и есть очень существенное отставание. Но наверняка это можно побороть. Остаётся передача команд роботу. Управление, по возможности, оставить бы прежним. Где это невозможно, обсудим и приведём к общему знаменателю.

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

Есть желающие взяться за такую задачку?

9 комментариев:

  1. Можно попробывать заюзать Google Cloud Messaging.
    Но есть сомнения по поводу скорости работы и возможности использования для других платформ сего чуда. Посему, другое решение -- использование web-сокетов.

    ОтветитьУдалить
  2. У меня нет опыта применения ни одного, ни другого решения. Google Cloud Messaging у меня тоже вызывает сомнения, как я понимаю, соединение будет уже не точка-точка. А web-сокет, кажется, построен на базе tcp-сокета. Tcp-сокет у Мити раньше был, и я от него отказался в пользу udp. Даже в пределах локальной сети при ухудшении сигнала wifi на tcp-сокете были задержки до 5 секунд. Udp датаграммы сейчас с этим справляются на ура. Дело в том, что положения джойстиков передаются постоянно, и потеря нескольких пакетов незаметна. А tcp подобных вольностей не прощает.

    ОтветитьУдалить
  3. RFC-6455 говорит, что web-сокет не обязательно по TCP.
    5 сек. это много конечно, но я не вижу другого адекватного и максимально независимого от платформы решения.
    Как вариант можно пооптимизировать протокол.

    Можно конечно посмотреть в сторону флэша и java-апплетов.
    Основной плюс -- возможность установления прямого соединения
    Основной минус -- страдает мультиплатформенность.
    (Есть ли другие +/-?)

    ОтветитьУдалить
    Ответы
    1. Нет, в п.1.7 сказано: "The WebSocket Protocol is an independent TCP-based protocol". Вдумчиво этот стандарт не читал, но "UDP" в этом документе не встречается.

      А вообще странно, я уверен должны быть способы отправлять UDP-датаграммы из браузера. Передача динамичного управления по TCP-сокету это утопия. Ведь 5 секунд, это возможная задержка в локальной сети, когда мой роутер непонятно чем занимался. А что будет в глобальной? Все быстрые игры используют UDP, а у нас тут вообще момент ответственный - пока TCP-сокет пыжится сдержать слово и передать пакет "стой!", робот уже убьёт себя об стену, или сбросится со стола. А вы будете наблюдать за этим на видео, там ведь UDP на низах.

      Если HTML5 настойчиво пытается захоронить Flash, может он может предложить что-нибудь взамен? Я тут совсем не специалист.

      Удалить
    2. Примеры использования websocketов внушают уверенность в том, что это уже вполне юзабельно :)
      раз -- чтобы увидеть эффект надо открыть два окна(можно и на телефоне))
      два
      три

      Удалить
    3. Интересно. Я посмотрел третий пример. Задержка максимум 1/2 секунды - вполне сносно. Всегда ли так? Надо разбираться, наверняка придётся переделывать Android-часть, а там для совместимости и Windows. Я пока пас – озадачен будущим сайтом и сенсорами ориентации телефона.

      Удалить
    4. По мне так третий самый тормозной из них:)

      Я правильно понимаю что:
      1. Состояние джойстика посылается постоянно?

      2. Схема работы примерно такая
      PC <--WiFi--> Android <--Bleutooth--> Arduino

      3. Причем, когда только передаются команды данные передаются только в одну сторону
      PC --WiFi--> Android --Bleutooth--> Arduino

      Дмитрий, Вы можете собрать некоторую статистику(лог) по работе программы? (в csv)
      Такие как:
      - количество отправленных с ЦУПа пакетов в секунду
      - количество полученных на Андройдофон пакетов в секунду
      - количество отправленных с Андройдофона пакетов в секунду
      - количество полученных на Arduino пакетов в секунду

      Для чистоты эксперимента хотелось бы чтобы в это время медиа данные не передавались. А еще лучше если будут логи без медия и с медиа.

      Удалить
    5. 1. Да постоянно. Точнее, только состояния двух джойстиков геймпэда.
      2. Да.
      3. Участок ПК - Android да, но скоро будет передача в оба конца. Участок Android - Arduino в оба конца.

      Залим, по статистике не имею ни малейшего представления как это сделать.

      Вряд ли вас интересует участок с Bluetooth. Но могу точно сказать, что там обмен редкий. Команды передаются только новые (отличающиеся от предыдущих того же типа). Т.е. повторяющихся команд для моторов и серв нет. Обратно идут ошибки, команды РобоСкрипта уровня телефона и сигналы от ИК сенсора (сейчас снятого - эхо робобитв). Всё это экзотика.

      На линии WiFi картина такая. Сейчас команды управления движением и ориентацией головы (4 команды по 7 байт) идут с минимальным интервалом 20 мСек. Каждая команда отправляется отдельным пакетом. Остальные команды посылаются редко, разово, по факту изменения состояния кнопок.

      На всякий случай... Ранее встреченные мной 5-ти секундные задержки при использовании TCP-сокета, не были связаны с перегрузкой канала управления роботом. Тогда повторяющиеся команды управления движением и головы роботу не посылались. Повторяться они стали только с переходом на более быстрый но ненадёжный канал UDP.

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

      Удалить