roboforum.ru

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

Там используется следующий алгоритм:
Сканируем входное изображение окном 80x80 с шагом 32 пикселя. По каждой области подсчитываем оценку возможности обучения (EstimateOpportunityForTraining) и если она больше 0.15, тогда проверяем, назначен ли этой области идентификатор, если нет, то обучаем AVM на эту область и назначаем для неё идентификатор.

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

Тут всё похоже на фильм «Матрица» когда вместо изображений мы видим символы, которые ассоциируются с тем или иным фрагментом изображения.

2EDV: Так что насчет проблемы на которую я указал? Ведь если у нас на изображении только вертикальная "зебра", то можно взять любой фрагмент 10%х10% изображения, включающий и черные и белые полосы хоть в какой части и ему пытаться обучиться, вот только как их между собой отличать?

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

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

2EDV: Нужно еще как! Нам нужно координаты относительные этих маяков, иначе теряется возможность SLAM делать.

Вообще при снятии маяков я предполагал делать так:
1. Снимаем картинку, проезжаем вперед 10см (примерно!), снимаем еще раз, проезжаем еще 10см (примерно!), снимаем еще раз.

2. Находим маяки (в т.ч. они чуть изменятся по масштабу, главное что не рассыпятся).

3. Из изменения масштаба определяем примерное расстояние до них (с некоторой погрешностью) и т.к. мы проехали 20см неточно (не ровно прямо) то определяем так же направления на них с некоторой погрешностью;

4. все это сваливаем в SLAM и радуемся получаемой и постоянно уточняемой карте местности и нашим в ней координатам

Это хорошо бы работало с «искусственными» (уникальными) маяками. А на практике получатся, что если поставить высокий уровень точности распознавания (3-х уровневое AVM дерево с ключём 80x80), то получим слишком много уникальных маяков и громадное дерево поиска, что убьёт быстродействие. Напротив, если использовать менее качественное распознавание (2-х уровневое AVM дерево, ключ 80x80), то в этом случае будут допускаться «ложные» срабатывания, что позволит обобщать большее количество изображений в один класс (символ), который закрепится за этой группой изображений.

Эти классифицированные символы изображения местами будут образовывать скопления (кластеры). Так вот кластеры, в этом случае, и можно принимать за маяки. То есть маяк – это не отдельный распознанный участок изображения, а группа распознанных участков объединённых по некому признаку.

Вот такое моё предложение

Добавлено спустя 12 минут 51 секунду:
Если маяк – это один распознанный фрагмент, то он может быть не очень устойчив (немого условия поменялись, и он не распознаётся). А вот если маяк – это группа распознанных изображений, то тут уже статистика, и если пару фрагментов и выпадет из распознавания, то не страшно.

2EDV: Не понял мысли - пофиг что будет считаться маяком, главное чтобы его координаты были стабильными, а не прыгали от кадра к кадру вверх-низ, потому что маяком мы посчитали фрагмент 5х5см с зебры

Добавлено спустя 1 минуту 45 секунд:
при этом группа таких фрагментов на зебре по моему критерию так же нестабильна, т.к. при смещении всей группы вверх-вниз - она будет замечательно опознаваться как "та же группа".

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

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

В топку пока карту глубины.

имхо - зря...

Зря - это когда мы не доделав одной простой вещи начинаем наворачивать проект
Ключевое слово в моём предыдущем сообщении - "пока".

Я тут на выходных ещё раз попробовал возможности управлять роботом, используя при этом входное видео с разрешением 320x240. Вдобавок я немного изменил алгоритм управления роботом (модуль Navigator.cpp) и результат получился просто замечательный. Итак, если у кого-то ещё нет электронного питомца, советую завести, так как алгоритм преследования для электронной «собачки» уже разработан, и лежит тут:
http://edv-detail.narod.ru/Navigator_src.zip

Всё оборудование, которое нужно для экспериментов, а именно: радиоуправляемая модель, видеокамера с радиопередатчиком и приёмником, аккумулятор (для видеокамеры), USB TV тюнер (для оцифровки сигнала от видеокамеры) общей стоимостью всего 150$. Так что если у кого то после просмотра видео появится желание присоединится к экспериментам по навигации, тогда бегом в ближайший магазин электроники и будем развивать идею дальше. Вместе веселее, а всё самое интересное ещё впереди.



Я обратил внимание на то, что у AVM на разрешении 320x240 достаточно большой запас по быстродействию, и у меня появилась достаточно интересная идея. Назовем это пока что «Location tree». Более подробно поговорим об этой идее, когда я проведу некоторые эксперименты, и у меня появятся первые результаты.

сделать бы еще ведение цели камерой и движение шасси в нужную сторону одновремененно, чтоб на терять цель.. как танки )

А это как раз и есть танк

Добавлено спустя 3 минуты:
И ведение «цели» приблизительно так и сделано (поворот башни/корпуса).