roboforum.ru

[mandigit]

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

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

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

Задача:
1. Предложить структуру системы взаимодействия
2. Предложить готовые решения для организации такого взаимодействия

[EdGull]

готов под это дело выделить грант в формате МиниБота 2.0

[=DeaD=]

Комплексное решение "в лоб" - CITRIX/RAdmin и т.п.

Добавлено спустя 1 минуту 5 секунд:
А вообще надо искать софтовое решение для прозрачной проброски COM-порта через TCP/IP.

[frig]

а идеальный вариант мне видится в реализации tcp/ip стека на самом роботе. тогда машинка выполняет роль маршрутизатора, либо при наличии wifi на роботе вообще потребуется только простенький soho роутер с wifi. вот тогда будет управление роботом через интернет. а так - управление машиной которая управляет роботом через интернет.

Комплексное решение "в лоб" - CITRIX/RAdmin и т.п.

имхо жирно будет по требуемой полосе.

А вообще надо искать софтовое решение для прозрачной проброски COM-порта через TCP/IP.

можно вообще попробовать замутить web приложение. на той самой машине, что подключена к сети - web сервер, на нем cgi приложение. тогда на другой стороне нужен только браузер, а значит прокатит и кпк и мобила.

итого - надобно написать то самое приложение.

Добавлено спустя 2 минуты 35 секунд:

А вообще надо искать софтовое решение для прозрачной проброски COM-порта через TCP/IP.

http://soft.mail.ru/program_page.php?grp=46572

оно?

[blindman]

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

[SMT]

Забавно - сегодня размышлял как это сделать, но не нашел как можно использовать, если нет видеокамеры.
Можно варианты использования (может это поможет с решениями)?

Недавно iRobot решили доработать своего робота iRobot ConnectR:

...After beta testing we discovered that ConnectR, in its current form, needed enhancements and modifications to meet customers’ expectations for virtual visiting. As such, iRobot has decided to cancel the current ConnectR program so that we can focus on developing new virtual visiting robots that incorporate your feedback...

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

[frig]

но не нашел как можно использовать, если нет видеокамеры.

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

[SMT]

выполнение действий в автономном режиме, но с коммандой к началу удаленно

например?

[frig]

например?

начать уборку, например.

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

[mandigit]

2All
Камеру рановато в общую кучу смешивать!

Решения по сквозной проброске COM портов попадались (правда коммерческие, есть еще opencom, но от него нужного добиться не удалось). Такое решение имеет, с моей точки зрения, недостатки:
1. COM порт ничего не знает о формате пакета и пытается байты группировать в пакеты исходя из каких-то своих внутренних соображений. Интернет работает пакетами. Хорошо-бы, если используемая технология это учитывала!
2. На компьютере, связанном с роботом требуется установка нестандартного программного обеспечения, чего, по-возможности, хотелось-бы избежать.

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

Наврное, Tcp/ip в этом случае реализуется на slip? А slip крутится в последовательном канале, который ему предоставлен.

[=DeaD=]

а идеальный вариант мне видится в реализации tcp/ip стека на самом роботе. тогда машинка выполняет роль маршрутизатора, либо при наличии wifi на роботе вообще потребуется только простенький soho роутер с wifi. вот тогда будет управление роботом через интернет. а так - управление машиной которая управляет роботом через интернет.

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

[frig]

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

как-то встречал проект по "превращению" дешевого свича в "управлямый". там tcp/ip был как раз на 32-й меге (если не вру) на сях. и вроде как реализация не единичная и проблема эта решенная. нам то скорости большие не нужны. а если нужны - то вопрос только в вычислительных мощностях.

Наврное, Tcp/ip в этом случае реализуется на slip? А slip крутится в последовательном канале, который ему предоставлен.

slip в смысле этот http://ru.wikipedia.org/wiki/SLIP ? канальный уровень вопрос второй. он может быть реализован и на тех же недоZigBee, что форумчане используют. со стороны робота просто модулем, на стороне роутера - переходник на ethernet (тоже вроде как на форуме кто-то занимался Ethernetом). и в роутер или свич, по сути уже не важно и не критично, так как ethernet да еще и ip сверху него это уже штука глубоко универсальная.

как то так в общих чертах видится.

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

не спорю. wifi - да, для крупных или когда нужна связь более чем точка-точка. ip - почему нет?

[=DeaD=]

не спорю. wifi - да, для крупных. ip - почему нет?

Какой КПД будет такого канала через UART 9600\115200 со всеми издержками?

[frig]

Какой КПД будет такого канала через UART 9600\115200 со всеми издержками?

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

[=DeaD=]

А смысл для любительской робототехники какой? У нас же реально всё равно ПК рядом стоит.

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

А что легко получится протоколы MSRS и всю их обёртку завернуть в TCP\IP я не верю, а уж про КПД там я вообще молчу.