Технический форум по робототехнике.
=DeaD= » 13 авг 2010, 09:25
Собственно пробую найти вариант который был бы читаем с максимального расстояния, в т.ч. очень слабенькими процессорами, пока мысль вот такая - как у EURO-NCap сделать центр для легкого распознавания этого самого центра + по кругу 8 бит в которых надо кодировать номер маяка инвариантно относительно вращения\отражения\ошибки в 1 бит. Маяков будет немного, зато должно получиться быстро и надежно.
Добавлено спустя 1 минуту 8 секунд:
Отношение центральный круг\внешний круг примерно 2/3...3/4.
- Вложения
-
- marks.png (11.38 КиБ) Просмотров: 3673
EdGull » 13 авг 2010, 09:25
это лучше твоих 2D-кодов?
=DeaD= » 13 авг 2010, 10:08
Ага, должно быть лучше по следующим причинам:
1. Это должно быть проще в распознавании, т.к. для детекция подозрительной на маяк точки будет независимой от масштаба и фактически будет выполняться обычным фильтром.
2. При движении даже при небольшом размытии когда мы не сможем прочитать код на маяке - если мы его уже прочитали и рядом нет других маяков - мы сможем понять точные координаты маяка не особо нагружаясь и отследить с предыдущего кадра его номер.
Michael_K » 13 авг 2010, 10:15
Вертикальных и горизонтальных линий и так много в нашем мире...
Почему бы не повернуть все это, скажем, на 45 градусов?
Код по кругу - не нравится...
Почему не просто штрих-код над меткой?
=DeaD= » 13 авг 2010, 10:18
1. Какая разница как оно повернуто? Детектору должно быть пофиг, маяк должен быть инвариантен относительно поворота.
2. Код по кругу не нравится - замечательный аргумент конечно, а что-то менее субъективное есть? (см. устойчивость к повороту)
Michael_K » 13 авг 2010, 10:22
1.
Исключатся ложные срабатывания на естественных горизонтальных и вертикальных палках.
(табуретка, шкаф, тень от них)
2.
Зачем нужна устойчивость к повороту?
=DeaD= » 13 авг 2010, 10:26
1. При чем тут палки? Наш детектор должен ловить не просто переход черное-белое вертикальный, а точку в которой сходятся 4 шахматные клетки.
2. Чтобы понимать свои координаты даже если мы стоим наклонно. Всякие тапки и прочая утварь по которой надо гонять - это никуда не девается.
Michael_K » 13 авг 2010, 11:35
Вертикальных и горизонтальных граней, границ свет-тень
в реальном мире больше чем наклонных... Если нужна инвариантность к повороту, то конечно по барабану, просто вероятность верного обнаружения снизится - только и всего...
Я уже когда-то писал вот
тут:
Для маяков, видимо можно выбирать формы инвариантные к масштабу
и направлению. Например поставить на пол подсвеченные изнутри конусы.
Тогда найденный на картинке яркий угол заданной величины и направленный
вверх - даст направление на маяк. Искать его будет заметно проще,
чем, скажем, штрихкод.
Зная высоту конуса, можно также ограничить область поиска.
Например, если их поставить так, чтобы вершины лежали в плоскости горизонта,
задача определения направления на маяк превращается в тривиальную.
Маяки могут различаться например углом, но может быть проще
задать положение маяков относительно друг-друга или можно подвесить
над конусом цилиндр с горизонтальными полосками или нанести
горизонтальные полоски прямо на конус.
AlfoGnom » 13 авг 2010, 11:40
А если попробовать
QR-Code? Хотя там уже расстояние будет значимо, из-за четкости изображения.
Но зато сообщение может нести больше полезной информации.К примеру координаты препятствия, его размеры, лучший маршрут объезда и т.д.
=DeaD= » 13 авг 2010, 11:42
QR-Code не эффективны как маяки для навигации по ряду причин, часть из них вы даже сами знаете. Предлагаю забыть про них в этой задаче.
AlfoGnom » 13 авг 2010, 11:47
А если взять за основу их алгоритм. "Обрезать" по ваши нужды?
Просто авторы QR-Code преследовали другую цель.
Думаю можно будет уменьшить размеры изображений и улучшить "распознаваемость".
Да и "квадратные метки", будет проще обрабатывать, нежели "круглые". Если учитывать нюансы машинного зрения(пиксели).
=DeaD= » 13 авг 2010, 13:19
На тему "проще обрабатывать" - вы уверены, что разбираетесь в предмете?
Добавлено спустя 33 минуты 30 секунд:Еще бонус - детекцию маяков можно будет делать на изображении сниженного разрешения и только подозрительные области разбирать с деталями.
AlfoGnom » 13 авг 2010, 13:51
=DeaD= писал(а):На тему "проще обрабатывать" - вы уверены, что разбираетесь в предмете?
Я имел ввиду, что распознавать "квадратики" легче, из-за.. хмм "пиксельной основы" картинки.
Хотя с большого расстояния четкость картинки точно будет снижаться(у камер с фиксированным фокусным расстоянием).. Тогда, действительно, может нет смысла именно в квадратных метках.
=DeaD= писал(а):Еще бонус - детекцию маяков можно будет делать на изображении сниженного разрешения и только подозрительные области разбирать с деталями.
Кстати при снижении разрешения тоже можно попасть в "ловушку", некоторые детали могут "быть просто не увиденными, отброшенными". Порог снижения разрешения, при котором будет выдерживаться необходимая четкость и распознаваемость надо будет тестовым путём искать, проверять.
Либо можно решить вопрос размытости, используя дальномер и изменять фокусировку камеры на нужное расстояние.
Zeus » 13 авг 2010, 14:15
Нормальный маяк.
Только вот 8-ми битный код считать будет трудно, если учитывать что камеру или маяк можно будет поворачивать. Надо какой-либо маркер нулевого бита ставить, наверное...
Последний раз редактировалось
Zeus 13 авг 2010, 16:25, всего редактировалось 1 раз.
=DeaD= » 13 авг 2010, 16:21
это понятно что реально не 8 бит будет, а меньше