Category: it

Category was added automatically. Read all entries about "it".

slow loris

Big Data, чтоб их ... (4)

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



где



Кстати, если сложить все Ak, мы должны получить единичную матрицу, что элементарно доказывается - матрица R вынесется за скобки, и тогда получится R-1R=E. Так что несмещённость результатов обеспечена.

Но когда я попробовал всё это посчитать, поначалу вышел полный бред - не выполнялось это условие, и всё тут, какая там единица на диагонали - нескольких порядков не хватало! Всё дело было в том, что я с какого-то перепуга подумал, что матрицы Ak получаются симметричными! Ну, как бы все матрицы Qk симметричны (для ковариационных это обязательно), и обратные к ним симметричны, и потом их сумма симметрична, и обратная к ней, т.е матрица R, также симметрична. А вот произведение двух симметричных - УЖЕ НЕТ.

Простейший пример:


А когда-то я об этом точно знал и написал процедуру перемножения симметричных матриц, дающую на выходе матрицу "общего вида". А сейчас у меня лежали эти матрицы в массиве 10х21 (десять симметричных матриц 6х6, для которых нужно 21 элемент), я попытался одну за другой умножать "на месте", а результат умножения (36 элементов) затирал соседнюю матрицу, вот всё и посыпалось как костяшки домино...

Кстати, из-за этого и выражение, как данные усреднять, я в прошлый раз неправильное привёл. Правильное вот:



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

Когда это дело подправил, получил довольно интересные результаты! Я боялся, что вообще получу практически единичные матрицы, или, по крайней мере диагональные (см. Big Data, чтоб их... (3)), но не тут-то было! Но чтобы понять, что это мне даёт, нужно ещё чуть подумать - вывести итоговую ковариационную матрицу результатов, если мы воспользуемся этими весами!

Collapse )

Приходим к удивительному результату: матрица R, которую мы посчитали ранее - это и есть результирующая ковариационная матрица, выражающая, как шумит наше усреднённое "по науке" значение.

Можно ли было это понять методом "пристального взгляда", обязательно ли было эти выкладки проводить - пока не знаю.

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

Потёмкинская деревня - 2

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

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

Вот что-то наваял...


Collapse )

По-хорошему, ещё денёк поковыряться - и я смогу уже "по-человечески" со своим прибором общаться, а не в шестнадцатеричных кодах через терминал :)

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

Big Data, чтоб их... (3)

"В предыдущих сериях": мой прибор выдаёт 6 значений: 3 координаты и 3 угла, т.е все 6 степеней свободы твёрдого тела. Причём ошибки измерения этих 6 значений сильно коррелированы между собой. Как именно - прибор знает, и выдаёт ковариационную матрицу шума измерений. Чтобы определить положение прибора на космическом корабле, я хочу провести где-нибудь N=10 опытов, располагая мишень на разных дальностях, измеряя её положение с помощью прибора, и, "контрольное измерение" - с помощью лазерного трекера, причём он будет мерять положение мишени в системе координат космического корабля. "Вычитая одно из другого", мы и должны раз за разом получать 6 параметров положения прибора на космическом корабле, но они будут зашумлены.

В прошлый раз я нашёл довольно простую формулу, с какими весами нужно сложить все 6N чисел, найденных за все эти N опытов, чтобы получить 6 искомых параметров, и чтобы свести шум к минимуму. Для этого нужно из ковариационных матриц шума измерений Qk (k-номер опыта) посчитать матрицу R:



и затем для каждого опыта найти свою матрицу весов, Ak



Тогда искомый вектор из 6 параметров выразится следующим образом:



(xk - вектор из 6 значений, измеренных в опыте k)

Интересный частный случай, если Q1=Q2=...=QN=Q, т.е от опыта к опыту ни дисперсии, ни ковариации не меняются. Такое может получиться, если мы дальность и углы не меняем особо, "топчемся на одном месте". Тогда данная формула очень существенно упрощается.

Collapse )
slow loris

Big Data, чтоб их... (2)

Вчера получил упоротое уравнение, чтобы найти, с какими весами нужно брать результаты измерений, чтобы получить наименее шумную и при этом несмещённую оценку вектора параметров:



Слева блочная матрица, составленная из ковариационных матриц шума измерений. Для простейшего примера, где N=M=2 (два параметра, измеряются дважды), всё получилось правильно.

Сегодня решил проверить ещё один "примитивный частный случай", когда M=1, то есть мы измеряем одну-единственную величину, но много раз (N раз). Пока ковырял его - нашёл, где ошибся с множителями Лагранжа, решил наконец через них - вышло существенно компактнее...

Collapse )

Можно одним махом находить веса для всех M параметров, что мы пытаемся оценить. Для этого находим матрицу R (от слова Reciprocal - "обратная"):



И затем нужные веса укладываются в N матриц Ak, каждая размером M×M:



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

Такое меня больше устраивает - не нужно эти жуткие блочные матрицы собирать, всё укладывается в размеры M×M, в моём случае 6×6 (три компоненты параллельного переноса и три угла)

Надо, правда, чтобы матрицы были невырождены, так что первый пример со 100% корреляцией здесь не пройдёт. Но "в реальной жизни" у меня 100% корреляции и не будет никогда, так что пущай!

Вот теперь пора это дело испытать на "модельных" результатах...
QuatCore

Быстрее, меньше, точнее!

Начинаем тестировать новую процедуру арктангенса. Сначала на симуляции. Получаем дамп памяти:


Переписываем числа в таблицу:


Первая половина таблицы очень многообещающая: ошибка не более 1 единицы младшего разряда, да и та случается в 6 случаях из 16, это уже прогресс по сравнению с предыдущим алгоритмом!

Но вот со второй половиной какая-то фигня: мы каким-то образом перепутали знак! Причём если посмотреть 4 варианта знака для (32052;6813):

(32052;6813)
(-32052;6813)
(-32052;-6813)
(32052;-6813)

то окажется: только когда оба числа положительных, мы выставили знак "+", во всех остальных случаях был знак "-".

Кто бы мог подумать: ассемблерная функция не заработала правильно с первого раза! Что ж, надо разобраться.

Collapse )

Итак: быстрее в 4 раза, меньше на 36 байт, точнее вдвое (максимальная ошибка в 1 единицу младшего разряда вместо 2). Чебышёв на пару с Ремезом рулят!

Наверное, пора успокоиться с арктангенсом и двинуть дальше. И макет довести уже до ума, и об его юстировке громко подумать...
QuatCore

Приводим в порядок знаки QuatCore

Громко подумали - теперь пора привести всё в чувства, во многом - вернуть как было! Мы несколько раз отказывались от оригинальной задумки, лишь бы программа, которую в этот момент писали, заработала как надо. Первый раз знаки нас не устроили (а всего-то надо было поменять адресацию - левому операнду i^j, правому i, а не наоборот). Вон, 8 июля 2019 года приводил ровно ту табличку, которую хочу сейчас, но когда дошло дело до реализации 3-го января 2020 года, почему-то она уже поменялась...

Сейчас наш модуль QuatCorePC (Program Counter) выглядит так:


Синим обведён модуль, который пора немножко помучать, NewQuatSigns. Видно, что сейчас он "подключён" к регистрам i,j, но вместо j надо взять k.

Collapse )

Осталось программу переправить, убедиться что "ничего не сломали" - и запустить наш многострадальный арктангенс!
QuatCore

Аффинный алгоритм+инф обмен, УСПЕХ

Когда первый раз увидел "целевую информацию", очень удивился значениям 0x0002, 0x0002, 0x0001, 0x01B7, 0x002A и 0xFE7E на месте ковариационной матрицы шума измерений. Ну, я знал, что ковариационной матрицы там пока нет, это пространство используется для "промежуточных вычислений", но мне казалось, там должна была лежать матрица аффинного преобразования, выражающая, как из координат мишеней "в метрах" получить их же координаты "в пикселях", чтобы они максимально соответствовали тому, что мы "увидели" на текущем кадре. Последние 4 значения соответствовали, а вот первые две "двойки" - бред какой-то...

Наконец, перечитав свои старые посты, разобрался, в чём же тут дело!
[Spoiler (click to open)]
Оказывается, первые два значения я "затираю" в процедуре нахождения масштаба. Раньше чебышевскую и манхэттенскую метрики я укладывал на стек ([SP] и [SP+1]), но решил [SP+1] не трогать, т.к там лежит "количество точек", которое ещё понадобится чуть позже.

Да, двоечка и там, и там - похожи на правду.


Вроде бы всё поправил - и нормировку, и "часы реального времени", прошиваю повторно - и опять чего-то не то...


Мне аж показалось, прибор меня материт как может! Там, где должны быть результаты (вектор и кватернион) - сплошные нули, и какие-то совершенно непонятные "промежуточные данные"...
Collapse )


Другое дело, никакой ругани, смайлики сплошные :)

Первый раз запросили целевую информацию - получили фактически нули. Затем послали "Синхронизация (с СД)" с нулевой отметкой времени и снова запросили целевую информацию. И затем ещё раз, только в этот раз слово данных 00 50, означающее, что прошло 80 раз по 100 мс. Смотрим ответы в двух последних случаях.

00 30, точнее 30 00 (вечно Endian мешается) - ответное слово, "всё в порядке".
3C 3C - заголовок массива "целевая информация".
01 00, точнее 00 01 - слово признаков (флагов), пока только один "зажжён", режим захвата.
Ещё раз 01 00, т.е 00 01 - метка времени, когда данные были обработаны. Да, на обработку ушло более 195 мкс, но меньше 390 мкс, всё правильно. Во второй раз 01 A0, т.е A0 01 - да, это взяли 7-битное значение 0x50, сделали эти 7 бит старшими (вышло 0xA000) и прибавили единичку, которая ушла на обработку. Всё верно.

00 00 - скорость сближения, её пока не считали
09 00, то есть 00 09 - общая экспонента для вектора. Означает дальность между 29-1 = 256 метров и 29 = 512 метров.
91 95, т.е 0x9591 = 38289 - мантисса для координаты X. В целом, дальность составляет 38289/32768 * 256 = 299,13 метров.
31 00, т.е 0x0031 = 49 - мантисса для координаты Y. В кои-то веки совпало с предыдущим разом. По-моему, тут я в 4 раза завысил величину, а должен получаться 9,5 сантиметра сдвиг вправо (корабль стоит совершенно строго на нормали к стыковочному узлу, в 300 метрах от станции, но прибор смещён на 9,6 сантиметра влево). Да, 49/32768 * 256 м / 4 = 9,6 см.

3d fe, т.е 0xFE3D = -451 - мантисса для координаты Z. Также в точности совпало с предыдущим разом. Это должно означать -451 / 32768 * 256 м / 4 = -0,88 м. Да, потому что мы стоим на 88 см ВЫШЕ стыковочного узла.

ff 7f, т.е 0x7FFF = 32767 - скалярная часть кватерниона, фактически единица.
А остальные компоненты нулевые. Всё верно.

Фуух, заработало...

Теперь хочу ещё реализовать atan(y/x) и с его помощью выдачу результатов в виде углов, а там пора и к обнаружению точек на изображении вернуться, я же это безобразие так и не отладил до конца!
Sidious

Как убрать "медузу" и прочий мусор из поисковой выдачи

Чего-то вдруг голландская компания yandex N.V стала настойчиво запихивать мне в глотку "медузу" по поводу и без. Ладно, ещё могу понять, когда я искал весёлую картиночку "Один МиГ - и вы в Белоруссии" и первые две ссылки вели на эту горгону и на эхо. Причём в этот момент я попросил яндекс больше не показывать эти сайты, но разумеется никакого эффекта моя просьба не возымела.

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

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

Пока результат такой: яндекс подобную фичу не поддерживает, а вот в гугле и DuckDuckGo можно этот процесс "автоматизировать", то бишь один раз вписать нелюбимые сайты - и искать без них :)

Collapse )

Не удивлюсь, если есть способ ГОРАЗДО ПРОЩЕ, просто не знаю, по каким словам его искать.
QuatCore

"16-битный" передатчик UART - окончание

Сегодня на удивление быстро с этой штукой разобрался:


Ну как, то есть я уверен, что UART работает правильно, что на 8 битах, что на 16, но почему-то алгоритм в этот раз точки в другом порядке расставил, и при попытке посчитать параметры сближения, получил крен 180° (!) и дальность меньше чем надо.

Ладно, с этим скоро разберёмся, посмотрю историю коммитов, что же я там поломал в последний раз, и нафига. А сначала подробности про UART.
Collapse )

"Ложная тревога": забыли в проекте "для железа" выставить параметр ijkEnabled=1, "включающий" одноимённую команду. А в данных алгоритмах она теперь вовсю используется, удобная вещь!

После очередного синтеза уже получил что надо:


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

А вот что за "мусор" внизу возник - ни малейшего понятия... Наверное, опять USB Blaster "шалит", а там посмотрим.
QuatCore

Оба алгоритма захвата - в загрузочный сектор! (512 байт)

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

Всего они заняли 254 слова кода, или 508 байт, то есть по-прежнему влезли в один блок внутренней памяти ПЛИС (БВП, он же EAB, Embedded Array Block). Ровно в той ПЛИС, которую я мучаю, 5576ХС4Т, таких блоков 24 штуки, а в той, куда хотелось бы вписаться, 5576ХС6Т (дофига радстойкая, в т.ч к тяжёлым заряженным частицам) - их всего 10.

Ещё один блок, как минимум, должен уйти на оперативную память.
Но ещё где-то два (один на оперативную, один на код) - под алгоритм обнаружения точек на фотоприёмной матрице, тот самый "супрематический", который я ковырял-ковырял, да так до конца ещё не отладил.

Итого уже 40% доступной памяти для ХС6Т мы заняли, а ещё алгоритм сопровождения нужен! Он довольно-таки "мерзопакостный"...

Collapse )

И поглядим, что получается "по дальней дистанции", старые добрые координаты, соответствующие 300 метрам "прямой наводкой":


Ярко-зелёным показаны 4 точки, после того как их идентифицировали. В этот раз наиболее удобным мне показался порядок МБД-МДД2-МДД1-МДД3.

Синим выделен вектор с общей "экспонентой" 9, т.е значения X (от 0 до 2), Y, Z (от -1 до +1) нужно домножить на 29-1 = 256 метра.

Имеем X = 0x9591 = 38289 = 1,168 (в формате Q1.15). Умножаем на 256 - и выходит 299,13 метров.
Далее, Y = 0x0031 = 49 = 0,00149 (в формате Q1.15). Умножаем на 256 - выходит 38 сантиметров. Похоже, я и тут пожадничал в 4 раза (чтобы точность не потерять раньше времени), на самом деле должно быть 9,5 см "сдвиг вправо", т.к смотрим мы "левым глазом", а летим прямо по курсу.

И наконец, Z = 0xFE3D = -451 = -0,0138 (в формате Q1.15). Умножаем на 64 (помня, что "пожадничали") и получаем -0,881 метра. Это мы сейчас установили "началом координат мишени" центр стыковочного узла, но прибор закреплён на те самые 0,881 метра ВЫШЕ, вот и воспринимает картинку как сдвинутую вниз.

Кватернион (выделен фиолетовым) вообще получился единичным, т.е выражающий нулевой поворот. Да, так и должно быть, идём "прямой наводкой".

Это у нас работа по модельным данным, я макет мишени дальней дистанции так и не собрал до сих пор, всё с ближней дистанцией возился. По модельным данным оно приятно - всё совпадает :)