roboforum.ru

Простое сравнение с шаблоном скорее всего ничего не даст.

Мне кажется, что эта задача, решенная от начала и до конца может в будущем иметь и большое практическое применение. Возможно, даже тянет на патент.

Не тянет. Такая задача решена уже много раз.

Виталий писал(а):Простое сравнение с шаблоном скорее всего ничего не даст.

Аргументы есть?

=DeaD= писал(а):Тупо с шаблонами сравнивать? координаты перебирать и хотя-бы 48 углов поворота - это уже 8*8*48 операций сравнения матриц размером 8*8, уже имеем 200'000 составных операций - и это только на 1 метку проверять, а если их куча? Мне кажется не проходим.

По-моим предварительным оценкам достаточно 8 углов поворота. Если матрица шаблона 8x8=64, то 512 операций. Весь экран 16x16, следовательно матрицу шаблона можно перемещать по i=0..8, j=0..8 - то-же 512. 512*512 = 262000 операций. Предположим на каждую операцию 10 тактов - получится 2,5*10^6 тактов. Что позволяет на 15МГц проводить идентификацию 6 раз/сек. Пока алгоритм не реализован точнее сказать сложно.

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

Идея - есть. Принцип может быть таким-же, как в автосигнализации.

=DeaD= писал(а):Это чтобы 1 метку распознавать, а 2 метки проверять - уже 3 раза/секунду будет?

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

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

=DeaD= писал(а):Вопрос в том, что в 16х16 пикселей очень мало чего помещается.

Белый квадрат окаймляющий метку какой шириной в пикселях гарантируем? Даже если 2 пикселя (а потом начинается другая метка), тогда уже надо не 16х16 пикселей, а 24х24 пикселя. Да и внутри 4х4 пикселя если могут быть любыми, это значит, что там может например не быть пикселей вообще и в координатах ячеек близких к (0,0) эти белые квадраты не ясно будет как искать, там будет чистый лист с одиноко стоящими пикселями.

Проблем - много. Нет 24x24 кадра, и памяти столько нет и вычислительного ресурса столько нет

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

Ладно, нужно все подетальней продумать!
Наверное, пока все обсудили!?

2mandigit: Ну еще не всё, есть еще мысль - может быть не выкладывать всю инфу в 1 маркер, а только частичную? Типа 4-6 бит и всё? И располагать их в некой регулярной структуре, тогда мы конечно имеем шанс проморгать маркеры и потерять координаты, но это надо подряд типа 3-4 маркера проморгать по 1 координате...

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

=DeaD= писал(а):2mandigit: Ну еще не всё, есть еще мысль - может быть не выкладывать всю инфу в 1 маркер, а только частичную? Типа 4-6 бит и всё? И располагать их в некой регулярной структуре, тогда мы конечно имеем шанс проморгать маркеры и потерять координаты, но это надо подряд типа 3-4 маркера проморгать по 1 координате...

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

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

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

С кучей градаций не покатит, а вот с некучей - вполне себе.