roboforum.ru

Есть такая идея-фикс Очень интересны роботы в разных вариантах - промышленные, домашние и т.п. Я думаю, тут у всех такая же идея.
Особенно мне интересно сделать робота, который сможет делать домашние дела - посуду, приготовить, погладить, пропылесосить, принести что-то и т.п.
Ту же задачу ставят перед собой ребята из WillowGarage. Они разрабатывают ROS, опен-сорс систему управления любым роботом. Но у них есть некоторые перегибы в плане доступности робота. Тот экземпляр что у них есть тянет на 15 штук, это цена неплохой тачки. Это явно не подходит под "робота для всех". Ну а я, начитавшись Форда, хочу сделать такого, который будет именно для всех. Это конечная цель проекта.

Что мне не нравится в ROS, так это их подход к полному моделированию и просчету всех движений робота. Да, это нужно. Но обычный манипулятор на FPGA осуществляет процесс хватания детали произвольной формы без проблем. Писали такой курсовик в универе Потом препод тестил (не наш, аналогичный алогритм) - шустро и быстро получается. Робот PR2 это делает весьма неторопливо.
Вторая вещь, которая не нравится в их работе - привязка к дорогому High-end оборудованию. Ну не нужна домашнему роботу возможность определять расстояние с точностью до милиметра с 30 метров

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

В качестве мозгов буду использовать комп под Убунту. Робот должен быть мобильным, поэтому мать с жесткими дисками, аккумуляторами и т.п. будет ездить на тележке. Из тех готовых тележек что я видел под мой вес (5-7 кг, чтобы можно было затем грузить чем-то еще) я не нашел ни одной, которая бы устраивала меня по цене. Меньше 700-800 за такую штуку я не видел. Поэтому хочу собрать сам, хотя в железках опыта практически нет. Опять же, хочется по максимуму использовать готовые компоненты, поэтому пока смотрю в сторону OpenRobotics.

Эта тема возникла отсюда: viewtopic.php?f=35&t=7443&p=147836
Там мне посоветовали сделать радиуправляемую платформу, которая будет маленькая и дешевая. А мозг пусть стоит и не бегает Действительно, так получается еще дешевле, однако есть несколько недостатков:
1) Если конечная цель будет достигнута, то сажать мозг на тележку придется все равно. Да, общая логика останется той же, но как поменяются "детали реализации"! Обычно именно детали срывают проект по срокам Поэтому чем ближе к боевым условиям сразу - тем лучше
2) Если эта тележка общается с компом по блютусу, то драйвер управления тележкой получается достаточно сложным - читать показания с камеры, дальномеров и т.п. Значит существенную логику придется перенести в МК, чтобы упростить управление тележкой. А это автоматически означает, что если какая-то деталь меняется, то переписывается прошивка МК. Это неудобно и неприятно.
Да, =DeaD= верно заметил в начальном топике:

konstantinmirin писал(а):Желание возникает потому что я хочу со всеми устройствами, которые будут у робота "общаться" в ROS через драйвера (существующие или самописные) Player. Если брать радиоканал, то все команды идут на МК, а он уже раздает все устройствам.

Крайне интересно, как минуя МК вы собираетесь управлять сервами, читать показания с дальномеров и рулить коллекторными движками? По моему один фиг придется ставить МК, а уж как этот МК соединен с ПК - вам не всё равно? Или блютуз или USB<=>UART адаптер.

Значит на каждое устройство свой МК (если это например шасси) или использовать устройства, которые совместимы с компом (например, веб-камера). То есть максимально отделить модули друг от друга, воспользовашись для этого архитектурой ROS и Player (драйвера которые там есть тут не подойдут, но принцип - вполне) Тогда получается гибкая и желеная и программная часть.

В принципе, даже при таком подходе можно сделать р/у часть. На каждый мк свой блютус и натыкать их в USB. Устройств пока что 3 штуки всего.

Обновление. В результате обсуждеия пришли все же к тому, что вполне можно начать с Р/у модели, но желание "на базе OpenRobotics" остается, потому что ORFA хочется использовать. Да и другие вещи понравились. Плюс полная поддержка этого проекта на форуме
Так что пока обсуждаем железки.


Прелесть ROS еще и в том, что можно использовать симулятор OpenRAVE, к которому все уже подключено, ничего не надо "допиливать".

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

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

Ближайшие планы:
1) защитить диплом (24-26 фев)
2) разобраться с кодом ROS и симуляцией
3) прикинуть примерный конфиг робота и смоделировать его, заменив бешенно дорогие лазеры простым дальномером и камерой
4) добиться нормального объезда препятствий в модели
5) собрать железку и покататься на ней
6) двигаться дальше с манипулятором

Обновление 2. В процессе обсуждения выяснилось что самая критичная часть робота - это стереозрение, позволяющее хорошо ориентироваться в пространстве. Так что план немного корректируется:
3) Собрать подобие "головы" в плане зрения (см viewtopic.php?f=35&t=7517&start=30#p148256)
4) Научиться с помощью этого строить 3Д модель
5) прикинуть примерный конфиг робота и смоделировать его, заменив бешенно дорогие лазеры простым дальномером и камерой
6) добиться нормального объезда препятствий в модели
7) собрать железку и покататься на ней
8 ) двигаться дальше с манипулятором

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

А, да, еще надо бы на базе этой работы написать кандидатсткую и защитить Это если в аспирантуру возьмут

Основная ошибка - нет никакого смысла массово делать робота, который будет тупо заменять человека

Когда делали стиральную машину - не придумывали робота с руками когда посудомоечную - тоже, когда робота пылесоса - тоже

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

А знаете, я бы не отказался если бы кто-то у меня в квартире убирал. Посудомойка + стиралка + кухарка + робот-уборщик явно больше 1К баксов. А я хочу поместиться в эту сумму.

К тому же решенные здесь задачи могут быть применены где-то еще.

Основная ошибка - нет никакого смысла массово делать робота, который будет тупо заменять человека

Я думаю, когда Форд сторил тачку, говорили то же самое про лошадь. А когда эппл создавали ПК, то про секретаршу

konstantinmirin писал(а):1) Если конечная цель будет достигнута, то сажать мозг на тележку придется все равно. Да, общая логика останется той же, но как поменяются "детали реализации"! Обычно именно детали срывают проект по срокам Поэтому чем ближе к боевым условиям сразу - тем лучше

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

konstantinmirin писал(а):2) Если эта тележка общается с компом по блютусу, то драйвер управления тележкой получается достаточно сложным - читать показания с камеры, дальномеров и т.п. Значит существенную логику придется перенести в МК, чтобы упростить управление тележкой. А это автоматически означает, что если какая-то деталь меняется, то переписывается прошивка МК. Это неудобно и неприятно.

С камеры передавать инфу надо минуя BT, по остальному читайте проект [[ORFA]] прошивка МК уже написана и используется, умеет работать почти со всем и еще много чего можно подключить не переписывая её

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

Неверное утверждение. Железная часть в этом случае получается раздутая, т.к. приходится каждый контактный бампер снабжать USB-портом. Это концепция Phidgets, но они явно уже не могут ей следовать по причине экономической нецелесообразности, да впрочем никогда ей полностью и не следовали. В проекте Open Robotics как раз нету этого бездумного изолирования устройств друг от друга и подключением к каждому USB-драйвера и своего МК, что сильно снижает стоимость проекта

konstantinmirin писал(а):В принципе, даже при таком подходе можно сделать р/у часть. На каждый мк свой блютус и натыкать их в USB. Устройств пока что 3 штуки всего.

Вы бы еще по своему ПК и Линуксу на каждый контактный бампер поставили, ну а что, всё в вашей идеологии ведь?

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

Неа, эта идея тоже не нова, она лежит в основе проекта Open Robotics

Могу помочь с железкой, есть у меня готовое шасси на колесах которое может вам подойти:http://roboforum.ru/viewtopic.php?f=10&t=4594, так как для использования в квартире оно оказалось немного больше чем надо, то пришлось вскоре отказаться от него (глупо конечно с моей стороны что построил такую "махину", но это было давно).

Робот от WillowGarage полносью оправдывает свое предназначение. Исследования. Это не массовый робот для всех.
Это тот вариант когда люди сделали робота с супер-мощным железом и сказали... теперь ваша очередь - пишите алгоритмы.

И тут исследователи в области ИИ забились в конвульсиях... теперь нельзя сказать что "у нас нет подходящего робота".

konstantinmirin писал(а):А знаете, я бы не отказался если бы кто-то у меня в квартире убирал. Посудомойка + стиралка + кухарка + робот-уборщик явно больше 1К баксов. А я хочу поместиться в эту сумму.

Между хочу и могу сейчас огромная пропасть

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

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

konstantinmirin писал(а):Я думаю, когда Форд сторил тачку, говорили то же самое про лошадь. А когда эппл создавали ПК, то про секретаршу

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

Добавлено спустя 1 минуту 36 секунд:

Виталий писал(а):И тут исследователи в области ИИ забились в конвульсиях... теперь нельзя сказать что "у нас нет подходящего робота".

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

=DeaD= писал(а):

konstantinmirin писал(а):1) Если конечная цель будет достигнута, то сажать мозг на тележку придется все равно. Да, общая логика останется той же, но как поменяются "детали реализации"! Обычно именно детали срывают проект по срокам Поэтому чем ближе к боевым условиям сразу - тем лучше

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

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

=DeaD= писал(а):

konstantinmirin писал(а):2) Если эта тележка общается с компом по блютусу, то драйвер управления тележкой получается достаточно сложным - читать показания с камеры, дальномеров и т.п. Значит существенную логику придется перенести в МК, чтобы упростить управление тележкой. А это автоматически означает, что если какая-то деталь меняется, то переписывается прошивка МК. Это неудобно и неприятно.

С камеры передавать инфу надо минуя BT, по остальному читайте проект [[ORFA]] прошивка МК уже написана и используется, умеет работать почти со всем и еще много чего можно подключить не переписывая её

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

=DeaD= писал(а):

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

Неверное утверждение. Железная часть в этом случае получается раздутая, т.к. приходится каждый контактный бампер снабжать USB-портом. Это концепция Phidgets, но они явно уже не могут ей следовать по причине экономической нецелесообразности, да впрочем никогда ей полностью и не следовали. В проекте Open Robotics как раз нету этого бездумного изолирования устройств друг от друга и подключением к каждому USB-драйвера и своего МК, что сильно снижает стоимость проекта

Все совершенно верно. Монолитное ядро проще и дешевле. Поэтому линукс так и написан, Столлман со своим навороченным просто не успел. А теперь к практической стороне. С одной стороны, вы правы, незачем это бездумно изолировать. А с другой, ведь невозможно же провести обработку сигнала с дальномера и камеры в МК! Значит придется это передавать на комп. Идем дальше. Берем камеру Х и дальномер Y. Пишем прогу для считывания с них данных и передачи в комп. А затем выясняется, что появился дальномер Z, который при той же цене что и Y дает более точные показания. И приходится переписывать программу для работы с ним. Программу для МК, я имею в виду. А у Васи нет денег купить дальномер Z, но он хочет учавствовать в работе над проектам. Поскольку проект дальше будет развиваться именно с дальномером Z, то Васе придется часть прошивки на МК при каких-то изменениях в структуре данных (которые передаются в комп) переписывать самостоятельно, компилить все и прошивать МК.
Если мы идем по пути "бездумного навешивания МК везде", то эта проблема решается средствами ROS/Player. И компилить/перепрошивать ничего не надо. Но я согласен что это увеличение стоимости. Но ведь никто не мешает на конечном изделии, когда алгоритмы отработаны полностью, слить управление устройствами в МК и упростить, да и удешевить конструкцию.
Есть еще один минус в одном управляющем МК. Невозможно имея хоть 10 ядер одновременно читать инфу и с дальномера и с камеры. Просто потому что МК один.[/quote]

=DeaD= писал(а):

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

Неа, эта идея тоже не нова, она лежит в основе проекта Open Robotics

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

=DeaD= писал(а):Что-то я не понял, при чем тут такое сравнение? Я говорю нет смысла считать, что будет эффективным робот с манипулятором, который будет стирать белье или мыть посуду. Для этого сейчас даже когда в доме прислуга всё равно юзают посудомоечные и стиральные машины, потому что экономическая эффективность.

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

Но вообще вы правы. Гораздо большее значение и смысл имеет применение найденных решений в промышлености. Или в управлении машиной например Это кстати идея-фикс №2

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

CiSi писал(а):Могу помочь с железкой, есть у меня готовое шасси на колесах которое может вам подойти:http://roboforum.ru/viewtopic.php?f=10&t=4594, так как для использования в квартире оно оказалось немного больше чем надо, то пришлось вскоре отказаться от него (глупо конечно с моей стороны что построил такую "махину", но это было давно).

Спасибо. Но пока кажется дороговато. Когда разберусь получше с ROS и моделированием и острее станет вопрос платформы, у меня изменится восприятие "дороговато"

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

Виталий писал(а):Робот от WillowGarage полносью оправдывает свое предназначение. Исследования. Это не массовый робот для всех.
Это тот вариант когда люди сделали робота с супер-мощным железом и сказали... теперь ваша очередь - пишите алгоритмы.

И тут исследователи в области ИИ забились в конвульсиях... теперь нельзя сказать что "у нас нет подходящего робота".

Они начали с концепции "доступного робота", во всяком случае в мае когда я возражал насчет требования 4х ядерного проца (а теперь у них 2 сервака по 8 ядер) и говорил что очень дорого, концепция была еще жива, но мне сказали что нафоне стоимости других подобных роботов, у них еще и очень дешево.

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

Добавлено спустя 37 минут 39 секунд:
Антон, скажите, а почему вы настойчиво предлагаете RC модуль? Ведь сложнее же получать инфу от каждого компонента по отдельности. Конечно, никто не говорит о том, что надо с компа контролировать углы поворота сервомоторов камеры или распределять напряжение между двигателями - это задача для МК. Но например получение и обработка инфы от камеры, получение положения манипулятора в пространстве (да, тут придется находить баланс между "каждым углом" и "общей моделью") и т.п. - это же чисто компьютерная задача, зачем гонять это через единственый МК на роботе?
Я не хочу сказать что вы неправы. У вас значительно больше опыта в этом вопросе, чем у меня. Просто удивляет такое радикальное отношение к идеям автономного робота. Я просто хочу узнать:
1) Какие есть преимущества у этого подхода, кроме стоимости.
2) Возможно ли использование подхода ROS к устройствам если мы пользуемся вашей рекомендацией по архитектуре? То есть устройствам одного класса общий интерфейс и потом драйвер к каждому такому устройству. Просто хочется контролировать узлы робота как отдельные устройства, а не всего робота как одно устройство.

А что использовать какой нибудь обыкновенный 4-ый пень (про мини, пико и нано итх уже упамянули), гордость не позволяет? Обязательно надо сервак ставить? - а представь скольлько он потреблять драгоценных Ач будет, да же при установке выше упамянутого на бота пентиума 4?

На будущее - за 1500 рублей отдам, а то стоит пылится и место занимает.

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

По пунктам:

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

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

konstantinmirin писал(а):По ORFA читал немного, но насколько я понял - это как общий контроллер, обращаться можно к любой периферии. Но обработка этой периферии все равно должна идти в МК. См ниже мои возражения.

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

konstantinmirin писал(а):С одной стороны, вы правы, незачем это бездумно изолировать. А с другой, ведь невозможно же провести обработку сигнала с дальномера и камеры в МК! Значит придется это передавать на комп. Идем дальше. Берем камеру Х и дальномер Y. Пишем прогу для считывания с них данных и передачи в комп. А затем выясняется, что появился дальномер Z, который при той же цене что и Y дает более точные показания. И приходится переписывать программу для работы с ним. Программу для МК, я имею в виду.

Неверно ORFA не осуществляет специфическую для устройств обработку, она тупо пересылает данные в ПК.

konstantinmirin писал(а):А у Васи нет денег купить дальномер Z, но он хочет учавствовать в работе над проектам. Поскольку проект дальше будет развиваться именно с дальномером Z, то Васе придется часть прошивки на МК при каких-то изменениях в структуре данных (которые передаются в комп) переписывать самостоятельно, компилить все и прошивать МК.

Тем более неверно, мы не планируем переписывать ORFA под каждое устройство.

konstantinmirin писал(а):Есть еще один минус в одном управляющем МК. Невозможно имея хоть 10 ядер одновременно читать инфу и с дальномера и с камеры. Просто потому что МК один.

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

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

Стандартизация только началась, и радует что мы не на самом последнем месте в этом процессе

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

Еще один миф надо не думать, что роботу платить не надо, а считать TCO (Total Cost of Ownership) = Совокупная стоимость владения. В ней есть и затраты на регламентное обслуживание и оплата вложений денег (можно было денежку положить в банк, а не купить робота, тогда бы % капали).

konstantinmirin писал(а):Но вообще вы правы. Гораздо большее значение и смысл имеет применение найденных решений в промышлености. Или в управлении машиной например Это кстати идея-фикс №2

Машинами уже управляют и уже даже не первый год, см. результаты Grand Challenge, единственное что радует - у них всё на радарах и лазерных сканнерах построено, так что в компактном применении типа домашнего робота это всё еще безумно дорого (см. PR2).

konstantinmirin писал(а):Антон, а вообще - огромное спасибо за обсуждение. Нигде до этого я такой аудитории как здесь не встречал

Ну вроде это крупнейший и самый "живой" форум по робототехнике в рунете так что не особо удивительно

konstantinmirin писал(а):Антон, скажите, а почему вы настойчиво предлагаете RC модуль?

Не понял мысли, наверное имеется в виду радиоканал

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

Еще раз:
1. Камеру не заводим на МК, в случае радиоканала ставим обычную аналоговую радиокамеру и транслируем видео через ТВ-тюнер на ПК;
2. Какая разница для программы на ПК через 1 канал драйверы устройств общаются с оконечными устройства или через несколько? Через радиоканал или нет? Через дополнительный i2c-канал после UART-канала или напрямую? Мы специально в проекте Open Robotics делаем максимально унифицированную и расширяемую платформу, чтобы можно было легко заменяя BT-модуль на модуль USB-UART моста и радиокамеру на вебкамеру без модификации софта перейти с радиоуправляемого робота на автономного и наоборот. И вообще не заморачиваться разрабатывая софт на борту комп или нет.

Добавлено спустя 2 минуты 18 секунд:
По поводу преимуществ радиоканала - в этом случае робот получается реально компактный и удобный для экспериментов дома, поверьте мне, у меня был опыт сборки робота на базе ноута полноразмерного: [[CVision Mobile Robot]], я знаю о чем говорю - было тупо страшно за домашнюю мебель и вообще если кому-нибудь в ногу въедет - может неслабый синяк посадить я уж не говорю о том, что перед экспериментами приходилось расчищать комнату чтобы не лабиринт был

Итак, если я делаю маленького робота, управляемого по радиоканалу, то:
1) вместо чтения с веб-камеры, мне надо читать с ТВ-тюнера => при переносе на полноразмерную платформу переписывается драйвер, возможно меняется скорость обмена данными и характеристики изображения
2) вместо работы, например, с дальномером, привязанным к COM-порту, я работаю с USB-портом, через который посылаю команды на МК робота и получаю данные с него. При переносе компа на платформу тут все ОК, потому что просто меняется штука в USB с блютус-адаптера на USB->UART плату.
3) Остается проблема одновременного доступа к нескольким устройствам. Допустим, мне надо одновременно читать данные с дальномера и крутить камеру. Да, понимаю, берем производительный МК и на таких задачах последовательная работа будет выглядеть как параллельная. Однако как разбираться с одновременным использованием канала двумя потоками? И как организовать "последовательное распараллеливание"? И это при том, что при создании полноразмерного робота это не надо. Просто подключаем как разные устройства и все.

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

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

3) одновременно значит, что у вас программа многопоточная. у вас она точно прям таки все даные парралельно обрабатывать будет?

как разбираться с одновременным использованием канала двумя потоками? И как организовать "последовательное распараллеливание"?

вполне решаемо простеньким протоколом

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

в большинстве случаев как раз наоборот. если вам с кучей контроллеров будет проще понять как это всё работает и реализовать, то почему бы и нет? вполне вариант, правда потом решиться всё переделать немного сложновато будет. вы кстати ради интереса представьте сколько в итоге вам нужно будет контроллеров и как это всё будет соединено проводами (питание, данные)

Штука которая крутит влево-вправо, вверх-вниз

pan-tilt, pantilt, pan tilt,...

Angel71 писал(а)::) в большинстве случаев как раз наоборот.

Аргументы? Я привел конкретную проблему, решения которой в рамках подхода "один МК и канал на все устройства" я не вижу. Как можно одновременно упавлять несколькими устройствами? Допустим мне нужен постоянный поток видео с камеры (реализовывается с помощью ТВ-тюнера и радиокамеры), постоянный поток данных с дальномера(-ов) (реализовывается с помощью опроса дальномеров микроконтроллером) и в это время - повороты камеры, управление колесами и т.п. Как контроллер, занятый опросом дальномеров (или других сенсоров) может делать что-то еще?
Единственный вариант здесь - это использовать параллельное программирование на компе с общим ресурсом "канал", который все юзают по мере необходимости. А МК с ORFA на борту здесь только как передатчик идет. В принципе не плохо, но появляются софтверные проблемы, которых при подходе "контроллер на узел" можно избежать - организация доступа к общему ресурсу (что-то типа монитора в Java => искать что-то похожее под С++), вместе с очередью, приоритетами и т.п. Плюс потенциальные тормоза. Да, глане тормоза будут при обработке видео и тормозить будет комп.
Но привязавшись к такому решению, потом будет сложнее от него отойти. Просто "переписать дрова и поставить" не получится.

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

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

Angel71 писал(а):3) одновременно значит, что у вас программа многопоточная. у вас она точно прям таки все даные парралельно обрабатывать будет?

как разбираться с одновременным использованием канала двумя потоками? И как организовать "последовательное распараллеливание"?

вполне решаемо простеньким протоколом

Ну вообще-то да, должна. Иначе я ограничиваю себя одним ядром без возможности переноса проги на многоядерные платформы.

А как это можно решить протоколом?

Добавлено спустя 5 минут 45 секунд:
Вы сообщение отредактировали пока я писал

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

Angel71 писал(а):если вам с кучей контроллеров будет проще понять как это всё работает и реализовать, то почему бы и нет? вполне вариант, правда потом решиться всё переделать немного сложновато будет

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

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

Angel71 писал(а):вы кстати ради интереса представьте сколько в итоге вам нужно будет контроллеров и как это всё будет соединено проводами (питание, данные)

Пока что - три штуки:
- pan-tilt
- Шасси
- дальномеры

Максимум что еще понадобится - 1 МК для манипулятора. Я что-то пропустил?

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

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