roboforum.ru

Ну первое - разбиваем задачу на понятные блоки, например:
1. Детекция объекта:
1.1. Определение объекта на плоском кадре;
1.2. Определение относительных (от камеры) координат объекта в 3D;
1.3. Доработка пункта 1 с учетом накопленной ранее информации и произведенных движений (а-ля Калман);

2. Матмодель объекта в статике:
2.1. Прямая кинематика;
2.2. Инверсная кинематика;

3. Алгоритмы управления верхнего уровня с учетом динамики манипулятора, чтобы он на каждый следующий момент не двигался, как будто не имеет скорости и момента инерции:
2.1. Для подведения манипулятора к зоне "уверенного поражения цели";
2.2. Поведения манипулятора в "зоне уверенного поражения цели" - захват цели и перемещение в корзину;


Далее каждый блок прикидываем как решаем, выписываем основные риски, как-то:
1. Получим фиговую точность;
2. Будет слишком долго обрабатываться;
3. Ваще непонятно как делать (маловероятно - это обычно надо решать на уровне декомпозиции);
4. Не сможем победить железяку;

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

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

Добавлено спустя 1 минуту 46 секунд:
Часть из этого была сделано, но принципиальные ошибки:
1. Вы смешали алгоритмические, софтовые и железные задачи;
2. Вы не оценили риски по задачам и не выбрали задачи, которые надо запротипировать в первую очередь.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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

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

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

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

Ну и про то, что пункт 1 вы так делали не верю - если вы сначала сделали пункт 1 - как он у вас потом мог сломаться? разве что совсем не на той камере или в других условиях освещения вы прототип делали.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

а ничего и не ломалось вроде... просто когда я отработанные задачи соединил вместе, все их косяки объединились и образовали замечательный синергетический эффект

IMHO:

Ну если всё делать на глаз, то итоговую неудачу конечно нечем больше объяснить

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

Строгие формулы ведь не обманешь, а вот обман зрения при работе на глаз - явление вполне регулярное

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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

Нет, возможно сразу были бы выбраны какие-то другие пути.

PS: А я предлагал не говорить - вы сами попросили

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Единственный путь - существенное увеличение бюджета, я бы не пошел на это

Или ввод нужного вида подсветки...

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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

да, но ведь ещё есть куда расти:
- таки разобраться с кодированием цвета камерой и передавать не 3, а 2 байта. тем самым повысив количество передаваемых кадров
- поэксперементировать с понижением битности цвета. обрезать или придумать какой алгоритм
- попробовать добавить датчик освещённости, возможно это существенно может облегчить процедуру изменения настроек камеры
- вместо передачи по uart использовать более скоростной spi->usb интерфейс
- ...

про 3/2 байта YUV я уже говорил, что это лишь вопрос итерпретации данных, а объем данных от этого не изменится.
ну уменьшу я глубину цвета в два раза, ну и будет у меня не 1.5fps, а 3fps, разницы не будет заметно...
почва для роста никудышная вот за 50-100 т.р., наверно, можно все сделать. еще раз напоминаю про запорожец и порше.

это не вопрос интерпретации, это 1 лишний байт, абсолютно не дающий увеличения количества информации, а возможно даже наоборот - уменьшающий её. нужно вникать как преобразование идёт, а это занятие бессмысленное.
1) 160*120*3*8=460800
2) 160*120*2*8=307200
3) 160*120*8=153600.
при мегобите fps будет:
1) 2,275555556
2) 3,413333333
3) 6,826666667
в 3 раза это очень даже неплохо, по крайней мере "никудышним" приростом это назвать сложно, ну если не летать в облаках. spi->usb позволит еще значительней увеличить fps. сразу можно было считать скорость и брать arm с usb, на цену этоб никак не повлиялоб. потянет текущий мк с такой скоростью с камеры данные получать или нет, другой вопрос. вникать детально во все аспекты данного проекта желания 0. будет у вас желание, вполне можно немного проапгрейдить ваше творение и довести fps до 30. по деньгам это не сильно много выйдет (если не покупать в горячке/спешке готовые платы, а самому делать).
а там дело ваше - хотите развивайте проект, хотите нет. тратьте хоть сотни рублей, хоть десятки тысяч.

Ну вообще это универсальный отмаз - "А что вы хотели за эти деньги, да за это время?"

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

Добавлено спустя 49 секунд:
Нет, разумеется обсуждение имеет смысл в гораздо более широких рамках, но не надо скатываться к безаппеляционному "а че вы хотели то?"

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Вот именно, что вы не хотите вникать. Посчитали байтики, и думаете, как все шоколадно. А какие разрешения при этом получаются, это не интересно ? Еще раз повторяю: соотношение объема данных к качеству изображения (будь то разрешение или глубина цвета) - ПОСТОЯННОЕ. Могу и в 3 раза уменьшить, но тогда и картинка будет в три раз меньше, точность в три раза меньше ! Это соотношение не изменить !
Возвращаюсь к аналогии с запорожцем и порше. Предлагаете, модернизировать ? Что ж, ну в первую очередь давате поставим на запорожец двигатель от порше за несолько тыщ баксов, но боюсь что он не впишется в систему, придется менять карбюратор, да еще добрую кучу устройств, да и систему подачи топлива тоже электронную надо поставить. О, да это не умещается сзади, надо корпус расширить. Нанимаем конструкторов за несколкь осотен тысчяч долларов они переплавляют корпус запорожца в порше. Ладно, сделали, все поставили. Может все-таки проще порше сразу купить, раз вы собрались гонять на скорости 200 км/ч с плавным разгонов АКБ и на комфортном кресле, и все это на запорожце ?

Добавлено спустя 3 минуты 19 секунд:
Да, но справделивый, а вы еще его оспариваете...