nabbla (nabbla1) wrote,
nabbla
nabbla1

Categories:

Тестируем алг. захвата в правой системе координат

В прошлый раз я неправильно задал "модельные" координаты обнаруженных точек, выбрав систему координат, принятую в компьютерной графике, где начало координат расположено СВЕРХУ СЛЕВА. То есть, ось X направлена вправо, а ось Y: вниз.

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


Для начала, та же самая картинка, просто у координаты Y меняем знак:

.data
;эти точки мы будем сортировать
Points2D:
;дистанция 0,5 метра, самое мясо
Fx0	Int16	14528	
Fy0	Int16	2944
Fx1	Int16	-14016	
Fy1	Int16	7872
Fx2	Int16	29376	
Fy2	Int16	11456
Fx3	Int16	22720	
Fy3	Int16	13568
Fx4	Int16	-18752
Fy4	Int16	20736
Fx5	Int16	-25664
Fy5	Int16	20800
Fx6	Int16	14848
Fy6	Int16	23488
Fx7	Int16	-9408
Fy7	Int16	27648


Напомним: взяли обычные координаты в пикселях, от 0 до 1023 по осям X и Y. Вычитаем 512, результат умножаем на 64, чтобы получить диапазон -32768..+32767. И теперь ещё обращаем знак по оси Y, чтобы она была направлена "вверх".

Нахождение двух самых отдалённых точек от этого не поменяется, как и сортировка вдоль оси, соединяющих их, как и поиск "центральных" точек. Если не ошибаюсь, изменится только знак проекции на перпендикулярную ось на последнем этапе. Я говорил, что вектор (-Vy; Vx) - это исходный (Vx; Vy), повёрнутый на 90° ПРОТИВ ЧАСОВОЙ СТРЕЛКИ. Так вот, это верно только в правых системах координат, а в левой это будет ПО ЧАСОВОЙ СТРЕЛКЕ.

Из-за этого, если оставить код без изменений, нумерация точек изменится. Но давайте всё-таки посмотрим, как это будет, вдруг новая нумерация нам понравится даже больше...

Заодно посмотрим первый раз на умножение матриц.

В этот раз проект отсинтезировался в 523 ЛЭ (это только ядро QuatCore, без периферии и видеопроцессора) и на предельную частоту 33,9 МГц. Забавно, замена 4j на 3j пошла ему на пользу :)

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

Вот дамп памяти:


На рисунке оно выглядит так:


Логично - то самое зеркальное отражение и получили. Почему бы и нет. Хотя... вместо того, чтобы на последнем этапе делать перестановки
1 <-> 6
4 <-> 7


(чтобы центральные точки убрались в конец массива), лучше вот так:
1 <-> 7
4 <-> 6


тогда нумерация будет более естественной:




Мы начинаем обходить все точки против часовой стрелки, так, чтобы центральные посетить самыми последними. Разумеется, дальнейшим алгоритмам абсолютно наплевать, в каком порядке идут точки, лишь бы всегда приходили к одному и тому же. Но ведь ещё будут люди, которым надо будет "вбивать" реальные координаты мишеней в ПЗУ, и если эти точки располагаются в каком-то "разумном" порядке, меньше шансов на ошибку.

И давайте ещё попробуем развернуть исходное изображение на 90 градусов против часовой стрелки, и посмотреть, что из этого выйдет. "обнаруженные точки" определим так:
;0,5 метра, поворот 90 градусов против часовой стрелки
Fx0	Int16	-11392
Fy0	Int16	-25664
Fx1	Int16	-11456
Fy1	Int16	-18048
Fx2	Int16	1152
Fy2	Int16	-14656
Fx3	Int16	-18368
Fy3	Int16	-9728
Fx4	Int16	6464
Fy4	Int16	14208
Fx5	Int16	-13696
Fy5	Int16	16000
Fx6	Int16	-5248
Fy6	Int16	23808
Fx7	Int16	-1600
Fy7	Int16	30400


Дамп памяти:


И эти же точки на изображении:



Шикарно! И такая нумерация точек мне больше нравится, и при повороте на 90° она не сбивается. Более экстенсивные тесты буду делать уже не вручную. Сначала надо будет сделать сколько-нибудь "штатный" информационный обмен с макетом, и там добавить возможность отключать обнаружение по изображению, а вместо этого подсовывать точки с компьютера, для отладки отдельных алгоритмов.
Tags: ПЛИС, программки, работа, странные девайсы
Subscribe

Recent Posts from This Journal

  • Тестируем atan1 на QuatCore

    Пора уже перебираться на "железо" потихоньку. Решил начать с самого первого алгоритма, поскольку он уже был написан на ассемблере. В программу внёс…

  • Формулы приведения, что б их... (и atan на ТРЁХ умножениях)

    Формулу арктангенса на 4 умножениях ещё немножко оптимизировал с помощью алгоритма Ремеза: Ошибка уменьшилась с 4,9 до 4,65 угловой секунды, и…

  • Алгоритм Ремеза в экселе

    Вот и до него руки дошли, причина станет ясна в следующем посте. Изучать чужие библиотеки было лениво (в том же BOOSTе сам чёрт ногу сломит), писать…

  • atan на ЧЕТЫРЁХ умножениях

    Мишка такой человек — ему обязательно надо, чтоб от всего была польза. Когда у него бывают лишние деньги, он идёт в магазин и покупает какую-нибудь…

  • Ай да Пафнутий Львович!

    Решил ещё немного поковыряться со своим арктангенсом. Хотел применить алгоритм Ремеза, но начал с узлов Чебышёва. И для начала со своего "линейного…

  • atan(y/x) на двух умножениях!

    Чего-то никак меня не отпустит эта тема, всё кажется, что есть очень простой и эффективный метод, надо только его найти! Сейчас вот такое…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 1 comment