roboforum.ru

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

Добавлено спустя 8 минут 33 секунды:
можете для упрощения части кода и упразднения излишней парралельности использовать событийную обработку инфы с датчиков. временами код в разы меньше и проще выходит, да и отлаживать проще

Виктор Казаринов писал(а):Меня устраивает viewtopic.php?f=10&t=7004
Идея с радиокамерой мне почему-то не понравилась. Но на вкус и цвет товарищей нет.

Принципиальных возражений по радиокамере нет
В идеале потом только драйвер поменять и все. А выходит реально дешевле и проще. Осталось решить проблему с параллельной обработкой.

Добавлено спустя 8 минут 42 секунды:
Событийнай модель - это прекрасная идея. Более того, это и есть самый правильный подход. Но параллельность это не отменяет Например, надо созадть событие "данные от дальномера" и передать его на комп. Когда создавать? Кто будет следить за тем, чтобы его создать? Прикольно было писать на прерываниях. Данные поступили - вот тебе и событие. Подумать надо, очень дельная мысль. Просто до конца проблему это не решает. Все равно надо по одному каналу передавать разные данные одновременно.

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

Angel71 писал(а): именно, за счёт протокола я и предлагаю.

Как? Просто пример протокола "на пальцах". Я на низком уровне практически не работаю, мне больше высойкий уровень симпатичен. Поэтому в вопросе организации протокола "плаваю"

Angel71 писал(а):а с парралельностью/псевдопарралельностью самой программы чесно говоря вообще никаких трудностей не вижу. "обычные проги" давно не пишу.

Верно, можно. Прога и так параллельная. Все что надо сделать - общаться с устройствами через один канал. И этот канал просто представить узлом (в терминах РОС) и сделать для него mutual exclusive доступ.
Минус подхода только в том, что появляется "узкое место".

konstantinmirin писал(а):1) вместо чтения с веб-камеры, мне надо читать с ТВ-тюнера => при переносе на полноразмерную платформу переписывается драйвер, возможно меняется скорость обмена данными и характеристики изображения

Я уж не знаю как другим библиотекам, но OpenCV пофиг с вебкамеры идёт картинка или с ТВ-тюнера;
Вам оно точно надо лезть в драйвера?

konstantinmirin писал(а):3) Остается проблема одновременного доступа к нескольким устройствам. Допустим, мне надо одновременно читать данные с дальномера и крутить камеру. Да, понимаю, берем производительный МК и на таких задачах последовательная работа будет выглядеть как параллельная. Однако как разбираться с одновременным использованием канала двумя потоками? И как организовать "последовательное распараллеливание"? И это при том, что при создании полноразмерного робота это не надо. Просто подключаем как разные устройства и все.

1. При создании полноразмерного робота это надо, т.е. вопрос экономической целесообразности.
2. Разделение канала реализуется библиотекой на ПК, как и в случае TCP/IP - есть соответствующий слой и всё.

konstantinmirin писал(а):Мне кажется, что вариант с отдельным контроллером на каждый узел не так плох как кажется.

Экономически нецелесообразно и технологически затруднено, ну и в целом нифига не нужно если это не смущает - делайте

konstantinmirin писал(а):Следуя концепции ROS, камеру надо поставить на "крутилку" (не знаю как это называется. Штука которая крутит влево-вправо, вверх-вниз) и представить ее в ROS как отдельный узел, с которого можно получать данные и которым управлять.

Концепция ROS не накладывает ограничения на железо и все устройства вполне могут находиться на удаленном роботе к которому идёт один TCP\IP канал.

konstantinmirin писал(а):С другой стороны, если можно без проблем организовать параллельную работу - то это супер.

Пока вы не обозначили никаких серьезных проблем.

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

konstantinmirin писал(а):Аргументы? Я привел конкретную проблему, решения которой в рамках подхода "один МК и канал на все устройства" я не вижу. Как можно одновременно упавлять несколькими устройствами? Допустим мне нужен постоянный поток видео с камеры (реализовывается с помощью ТВ-тюнера и радиокамеры), постоянный поток данных с дальномера(-ов) (реализовывается с помощью опроса дальномеров микроконтроллером) и в это время - повороты камеры, управление колесами и т.п. Как контроллер, занятый опросом дальномеров (или других сенсоров) может делать что-то еще?

А как вообще тысячи пользователей через один и тот же магистральный интернет-канал работают? И ничего, не хрюкают

konstantinmirin писал(а):Но привязавшись к такому решению, потом будет сложнее от него отойти. Просто "переписать дрова и поставить" не получится.

Какие есть мысли по этой проблеме?

Как раз перейти от такого решения к разветвленному никакой проблемы. Просто в драйвере, в адресе устройства записывайте не только i2c-адрес контроллера на шине, но еще номер COM-порта с которым работаете, а потом если что ставите 2 usb-uart моста и часть адресов переписываете на другой COM-порт. Всё давно продумано логика полностью взята с годами проверенного решения - интернета.

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

Вопрос не в том, решается это или нет, вопрос в том, что это не является проблемой в таких задачах

konstantinmirin писал(а):Я думаю что найдя "золотую середину" - один МК на ГРУППУ узлов (на 4 колеса например, на два привода pan-tilt и т.п.) можно построить вполнеприлично работающую машину.

Безусловно, там же вы поймёте, что нафиг не надо несколько МК, если конечно портов этого МК хватит

konstantinmirin писал(а):Тут просто прикол - меньше железок - больше програмить; больше железок - меньше програмить. Но кроме количества кода беспокоит еще и быстродействие.

Прикол в том, что "больше программить" МК мы уже закончили - берите ORFA и юзайте

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

konstantinmirin писал(а):Событийнай модель - это прекрасная идея. Более того, это и есть самый правильный подход. Но параллельность это не отменяет Например, надо созадть событие "данные от дальномера" и передать его на комп. Когда создавать? Кто будет следить за тем, чтобы его создать? Прикольно было писать на прерываниях. Данные поступили - вот тебе и событие. Подумать надо, очень дельная мысль. Просто до конца проблему это не решает. Все равно надо по одному каналу передавать разные данные одновременно.

Забудьте пока про событийность, реализуйте её на уровне ПК, а через МК тупой опрос. Как только дорастете до задач где реально не будет хватать тупого опроса - там обсудим а пока это придумывание вопросов на свои ответы

konstantinmirin писал(а):Верно, можно. Прога и так параллельная. Все что надо сделать - общаться с устройствами через один канал. И этот канал просто представить узлом (в терминах РОС) и сделать для него mutual exclusive доступ. Минус подхода только в том, что появляется "узкое место".

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

Практически убедили

Я уж не знаю как другим библиотекам, но OpenCV пофиг с вебкамеры идёт картинка или с ТВ-тюнера;
Вам оно точно надо лезть в драйвера?

Ага, точно. Для OpenCV разницы нет, а код, который берет картинку с ТВ или с веб-камеры будет отличаться. Правда наверное вы правы - не настолько чтобы стать проблемой.

Концепция ROS не накладывает ограничения на железо и все устройства вполне могут находиться на удаленном роботе к которому идёт один TCP\IP канал.

Верно, к каждому устройству свой TCP/IP канал. Если это можно реализовать через 1 МК, то проблемы вообще нет.

Не обязательно выносить этот канал на уровень ROS, хотя наверное желательно.

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

Как раз перейти от такого решения к разветвленному никакой проблемы. Просто в драйвере, в адресе устройства записывайте не только i2c-адрес контроллера на шине, но еще номер COM-порта с которым работаете, а потом если что ставите 2 usb-uart моста и часть адресов переписываете на другой COM-порт. Всё давно продумано логика полностью взята с годами проверенного решения - интернета.

Я не до конца понял, как это сделать. То что надо юзать вариант с инетом - это верно, никаких вопросов. Да, куча пользователей юзает 1 канал и все довольны. Коммутация пакетов рулит. Если здесь сделать так же - будет круто.
Я просто не знаю как это сделать

konstantinmirin писал(а):Я не до конца понял, как это сделать. То что надо юзать вариант с инетом - это верно, никаких вопросов. Да, куча пользователей юзает 1 канал и все довольны. Коммутация пакетов рулит. Если здесь сделать так же - будет круто. Я просто не знаю как это сделать

А в чем может быть проблема? Пишете на ПК сервер который обрабатывает запросы скармливая их ORFA и получая ответы, общаетесь с этим сервером хоть с 50 разных процессов параллельно. Сервер разруливает порядок трансляции запросов - хотите ставьте приоритеты, хотите тупо FIFO, в общем как угодно его настраиваете.

То есть просто коммуникационный РОС-узел, который все юзают.
Попробовать можно

Итак, едем дальше. Сам робот. Должен на себе везти манипулятор, аккумулятор, две камеры на pan-tilt, дальномеры. Возможно какие-то еще сенсоры по мелочи. Это естественно не разу. Но весь фарш должен выдерживать. Время автономной работы - полчаса хватит. Вообще говоря, меня даже робот на "хвостике" поначалу устроит. Большой хвостик сделать - не вопрос, а с питанием может вопрос упростится.
Из задач движения - ну кататься должен, разворачиваться, пороги до 1 см преодолевать, на ковер заезжать.

Что порекомендуете? Хотелось бы подешевле, но сидеть месяц с паяльником экономя 100 баксов тоже не хочется Так что надо где-то посередине.

Рекомендую на первом пункте постараться забыть про 2 камеры и попробовать работать на базе 1 камеры.
Хвостик - отстой

В качестве примера можно глянуть на:
wiki/OR-VL-SRV-v1
wiki/OR-MRBT-v2

Ну и позадавать вопросы

Наколько я вижу, вариант с гусеницами, во-первых, несколько больше, значит есть возможность куда-то прилепить потом манипулятор и вторую видеокамеру. Во-вторых, несколько дешевле. В третьих, корпус уже практически готов. В-четвертых, я так понял, что прогресс работы с ним пошел дальше
С другой стороны, у колесного есть то преимущество что контроллер у него с расширенной поддержкой сервоприводов, то есть последующее подключение манипулятора, второй камеры и других движущихся частей будет проще.
Я все правильно понял? Есть какие-то отличия что я упустил?
Если все верно, то может быть мнеимеет смысл взять за основу OR-MRBT-v2, но поставить в него контроллер от OR-VL-SRV-v1 и будет мне расширяемое счастье

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

Добавлено спустя 2 минуты 42 секунды:
А, еще, а где найти USB-тюнер для этих целей за 30 баксов, который бы поддерживался убунтой Пока нашел только это: AVerTV Volar AX, но оно 60-80, а не 30
Аналогичный вопрос по модели камеры.

Добавлено спустя 8 минут 5 секунд:
Появилась мысль насчет "слушать". Это ж реализовывается элементарно если взять радиокамеру со звуком. Дороже конечно, но зато никакой мороки.

1. Модель на гусеницах очевидно менее надежна с точки зрения износа, т.к. там пластиковые шестерни, китайские игрушечные моторчики и т.п. И шумит она больше. А в колёсной - сервоприводы с мет. шестернями и колесо подкатное мебельное

2. Сервоконтроллер не рулит коллекторными движками, для этих целей скоро будет OR-AVR-M128-DS, в котором будет 16 сервопортов и порты для управления коллекторными движками. Сейчас пробные платы в изготовлении, скоро их доделают и буду собирать пробные 2 экземпляра модуля.

3. Забудьте про вторую камеру, сильно увеличивает бюджет проекта и сложность (тв-тюнер с 2 входами или 2 тв-тюнера - еще та проблема). Да и немного будет народу с 2 камерами.

4. Забудьте про слух на роботе, при движении будет ноль информации, да и вообще для начала поставите микрофон на ПК, вы же в одной комнате будете все делать, какая разница где слушать? Сначала научитесь его использовать, потом тащите на робота.

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

1. Да, с надежностью все ясно, меня привлекла возможность разместить больше хлама Ну в принципе я думаю что если взять платформу из OR-VL-SRV-v1 и пределать к ней еще кусочек оргстекла позже когда нужно будет больше места - не самая большая проблема.
2. Если удет готово - возьму ее, я все равно не прямо сейчас собираю.
3. А стереозрение? Поскольку главное для чего делается этот робот - это эксперименты с распознаванием, то может имеет смысл действительно взять две веб-камеры, закрепить на двух сервах (чтоб могли крутиться), завести сервы на контроллер OR-AVR-M128-S. К этой же базе прикрепить дальномер и на это закончить. То есть передвигатсья конструкция не будет, будет только стоять на месте в радиусе 1-2 метра от компа. Если очень понадобится, можно к ноуту прицепить и протестить по квартире. Для экспериментов над зрением достаточно. А когда получится, то можно думать уже как две камеры вывести на мобильного робота. Во всяком случае, уже будут реальные успехи. Задача "собрать тележку" точно решама в предсказуемые сроки. А вот зрение - нет
4. Та мне это вообще не надо, братан хотел поставить микрофон динамик, чтобы сидя за компом можно было ездить по квартире, смотреть и общаться Короче, этот пункт вычеркиваем до лучших времен.
5. Понял.

1. Не особо больше хлама получится разместить
3. Радиокамеры на 2 канала посложнее достать будет, да и вообще я бы постарался отказаться на первое время от стереозрения, т.к. очевидно человек без него как-то справляется. А потом добавить лишний источник информации ничего не мешает

1. Значит придумаем как разместить больше. В конечном счете я же непривязан к той платформе. Можно сделать так же, только без

2. Человек справляется на основании большого опыта и еще кучи знаний. За счет того что может определить, какой объект ближе по их материалу, освещенности. И там еще куча других моментов выделено. Я видел это дело в книге по машинному зрению (Шапиро и Стокман), но не помню сейчас потому что читал ознакомительно.
Для построения 3Д модели мира робота ему нужен либо лазерный сканер за 3-5К, либо вторая камера и крутой алгоритм

В общем в результате мне больше всего понравилась идея вообще не движущейся платформы для начала
С радиокамерами разберемся если будет реальный результат. Даже две камеры+два ТВ тюнера тянет максимум на 300 баксов, но не на 3-5К. Но это конечно извращение. Короче придумаем, научиться бы обрабатывать результат хорошо

2) либо перемещать робота, либо, либо, либо........................
это я так, к слову