nabbla (nabbla1) wrote,
nabbla
nabbla1

Categories:

Алгоритм сопровождения зафурычил на 16 битах!

Пока что на "модели", в ассемблер Quat Core ещё не переписывал. И ещё остаются "вкрапления" плавающей точки: вектор параллельного переноса (характеризующий дальность и активные углы стыковки: курс и тангаж) пока что в плавающей, и вычисления матрицы 6х6 и вектора 6х1 пока что в плавающей точке, только потом с нужным масштабом оно приводится к 16-битным целочисленным значениям. А вот кватернион взаимной ориентации уже целочисленный на всём протяжении.




Чтобы выбраться из прокрустова ложа, я заменил UDUT (или LDLT)-разложение на UUT-разложение. Оно хоть и с квадратными корнями (целых 6 штук, у нас можно снизить до 5, т.к два нижних элемента ВСЕГДА одинаковы, а между ними ноль!), зато оказывается более устойчивым в нашей ситуации, когда динамический диапазон "поджимает".

И ещё одно "жульничество" - сейчас я очень активно пользуюсь целочисленным делением, т.к здесь зачастую появляются малые коэффициенты, которые надо поделить на другие малые коэффициенты. В такой ситуации, умножение на обратную величину требует масштабирования, причём если сделать его фиксированным (т.е обратные величины принимают значения от 0 до 256, при тех же 16 битах), то несколько упадёт точность. Хотелось уже, чтобы заработало поскорее. Теперь попробую и от делений уйти, и найти подходящий для нашего процессора алгоритм извлечения квадратного корня.

На графике выше приведена ошибка измерения дальности. Как видно, "низкочастотная" компонента ошибки неизменна, но при целочисленном исполнении добавляется "высокочастотная". Она выражена на больших дальностях, дальше существенно ослабляется. В целом, среднеквадратичное значение ошибки для 16-битного исполнения выше на 21%. Можно было бы и получше, но в целом - сойдёт. Надо ещё учесть, что от нас просят измерять дальность с точностью всего 5%, либо 5 метров на дальностях 100..300 метров, а реально достигаемая точность - на порядок выше.

С другой стороны, именно значения дальности мы используем для вычисления скорости сближения, и вот тут ходим "по бровке". Сюда добавить 20% погрешности очень не хотелось бы. Но как оказывается - и не добавляется:


Поскольку мы всё равно вынуждены вычислять скорость по точкам на интервале до 4 секунд, то все эти "высокочастотные компоненты" уничтожаются почти в ноль. Среднеквадратичное значение ошибки для 16-битного исполнения выше на 2% - очень даже.

Дальше идут значения углов курса и тангажа. Это величины, которые удаётся измерить точнее всего, ведь это в очень большой степени ПРЯМЫЕ измерения - положение центра оптической мишени в поле зрения! От нас требуют точности в 0,1° (6 угловых минут), это жесткое требование в том плане, что нужно правильно юстировать оптическую систему, хорошо сконструировать её, чтобы в процессе выведения на орбиту она никуда не "уехала", а вот случайная компонента ошибки очень мала. В конце концов, угловой размер одного пикселя у нас составляет 24/1024 = 0,023 градуса, а в действительности удаётся измерить яркостный центр с точностью до 1/20 пикселя. А вот дискретность наших результатов в 16-битном исполнении уже даёт о себе знать!





Среднеквадратичная ошибка при целочисленном исполнении выше на 5% для курса и на 24% для тангажа, но я бы не стал сильно из-за этого переживать.

И наконец, измерение взаимной ориентации, или, другими словами, крена и пассивных углов тангажа и курса. Как ни удивительно, однако здесь целочисленный алгоритм сработал гораздо ЛУЧШЕ, чем алгоритм с плавающей точкой!


Подозреваю, что здесь малая дискретность сработала как Noise gate: если алгоритм с плавающей точкой пытался честно по малейшим отклонениям точек на матрице понять, с какого ракурса мы смотрим на мишень, то целочисленный получал входное воздействие строго НОЛЬ, и оставлял ориентацию как есть, и только при существенном отклонении уже сдвигался.

В итоге, среднеквадратичная ошибка измерения взаимной ориентации при целочисленном исполнении НИЖЕ на 16%.

Пройдена вся дистанция от 300 метров до 0,5 метра, но пока что только "прямой наводкой". Сейчас надо будет опробовать ещё 5-6 других направлений, но в целом уже видно - подход вполне рабочий! Те величины, измерение которых весьма проблематично, измеряются этим методом ничуть не хуже, а те, где и так был гигантский запас - ну чуток хуже, но там систематические погрешности всё равно превалируют.
Tags: ПЛИС, кватернионы-это просто (том 1), математика, работа, странные девайсы
Subscribe

  • Я создал монстра!

    Вот нормальная счастливая пара разъёмов ОНЦ-БС-1-10/14-Р12-2-В и ОНЦ-БС-1-10/14-В1-2-В: У розетки кроме основного выступа, отмечающего "верх",…

  • Нахождение двух самых отдалённых точек

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

  • Слишком общительный счётчик

    Вчера я чуть поторопился отсинтезировать проект,параметры не поменял: RomWidth = 8 вместо 7, RamWidth = 9 вместо 8, и ещё EnableByteAccess=1, чтобы…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 8 comments