roboforum.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=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 к устройствам если мы пользуемся вашей рекомендацией по архитектуре? То есть устройствам одного класса общий интерфейс и потом драйвер к каждому такому устройству. Просто хочется контролировать узлы робота как отдельные устройства, а не всего робота как одно устройство.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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