Создание собственной системы стабилизации
Теперь можно все в даблах считать
Это хорошо конечно, но мне например, пока не понятно где востребована такая повышенная точность, уж больно источники “сырых” данных неточные чтоб их в даблах обсчитывать… (приведите пример)
Что за новый кортекс?
M7 по всей видимости…
Это хорошо конечно, но мне например, пока не понятно где востребована такая повышенная точность, уж больно источники “сырых” данных неточные чтоб их в даблах обсчитывать… (приведите пример)
например барометр ms5611
например барометр ms5611
Сергей, а по моему без всяких даблов, он обсчитывается с физически предельной для него точностью, не? , а повышать разрядность шумов не вижу смысла…
Что за новый кортекс?
Оптимизация при сборке была включена или выключена?
кортекс-М7
Оптимизация включена, без оптимизации что-то лишнее добавляется, а так с = а * b выполняется за 6 тактов, дальше зависит от скорости флеша, шин и всяких кэшей
Это хорошо конечно, но мне например, пока не понятно где востребована такая повышенная точность, уж больно источники “сырых” данных неточные чтоб их в даблах обсчитывать… (приведите пример)
если есть аппаратная поддержка двойной точности то почему бы ее не использовать, задачу всегда можно найти))).
повышать разрядность шумов не вижу смысла…
ну как бы так:
const double T1 = 15.0 + 273.15; /* temperature at base height in Kelvin */
const double a = -6.5 / 1000; /* temperature gradient in degrees per metre */
const double g = 9.80665; /* gravity constant in m/s/s */
const double R = 287.05; /* ideal gas constant in J/kg/K */
Оптимизация включена, без оптимизации что-то лишнее добавляется, а так с = а * b выполняется за 6 тактов
a,b внутри цикла не меняются, с - нигде не используется. Оптимизатор это вообще из цикла выкинуть может. Не очевидный какой-то тест.
a,b внутри цикла не меняются, с - нигде не используется. Оптимизатор это вообще из цикла выкинуть может. Не очевидный какой-то тест.
ну это я как пример привел, конечно я смотрел чтобы компилятор не выкинул код. Я смотрю асемблерный код в отладчике как выполняется. Если тест не очевидный то какой очевидный?
без оптимизации будет 90мс, компилятор какието лишние инструкции добавляет.
без оптимизации будет 90мс, компилятор какието лишние инструкции добавляет.
Снег дело говорит:
a,b внутри цикла не меняются, с - нигде не используется.
при компиляции вся операция выкинется, так как результат её дальше не используется, нада так:
for(int i=0;…){ c += a* (double)i; }
printf(“%f”,(float)c) ;
никуда компилятор ничего не выкидывает, можно же объявить так
volatile double a;
volatile double b;
volatile double c;
вот асемблер какой получается
c = a * b;
LDR.N R0, [PC, #0x20]
VLDR D0,[R0, #0]
VLDR D1,[R0, #+8]
VMUL.F64 D0,D0,D1
VSTR D0,[R0, #+16]
Это при максимальной оптимизации. Оптимизация убирает лишнии копирования из памяти в регистры процессора и обратно. Фишка в том что VMUL.F64 D0,D0,D1 выполняется за один такт.
так выглядет без оптимизации:
LDR.N R0,[PC, #0x2С]
VLDR D0,[R0, #0]
LDR.N R0,[PC, #0x2С]
VLDR D1,[R0, #0]
VMUL.F64 D0,D0,D1
LDR.N R0,[PC, #0x24]
VSTR D0,[R0, #0]
даже если посчитать такты нужные для выполнения инструкций то примерно похоже на правду.
ну как бы так:
Забавно… Типа - температурная поправка воздух/высота требует большего числа знаков… Не уверен что сенсор измеряет реальную температуру воздуха … Надо проверять.
Если кому интересно, сегодня возникла надобность раздербанить назу)))) Походу закис шлейф и выдавало по одной из осей ошибку, но я раздербанил все и посмотрел как там все устроено.
Фото увы не делал да и не на что там особо смотреть.
Собственно как устроена виброразвязка: От металического кубика с датчиком идет шлейфик и соответственно все это держется на оч мягкой пенорезине, вот только есть один нюанс (как в анекдоте) кубик этот полый и датчик залит внутри при помощи эпоксидки (увидеть это не сняв кубик невозможно). Так что по сути кубик это монолит в центре которого датчик.
И кстати что заметил не знаю баг это или фича, но кубик был теплый (перед этим включал назу мин на 5-10) так что возможно он еще и изнутри подогревается, но насчет этого я не уверен.
Да наза починилась)))) так что дербанил не зря)))
подогревается модулем Пельтье - это мы уже выяснили давно, да и что за датчики тоже (теоретически и по рассказам таймкопа) скажу так на датчиках которые мы используем - это не надо, ну разве что в 40 градусный мороз…
я тут для gps фильтрик посчитал маленький на 5 листов А4 теперь репу чешу как его в мегакод превратить )))))
репу чешу как его в мегакод превратить
Чё,помочь ?
скажу так на датчиках которые мы используем - это не надо, ну разве что в 40 градусный мороз
в 35 градусный точно не надо, проверено )
Чё,помочь ?
не, в проц упёрся ))) на каждой интерации извращение одно делать надо так что проц только с fpu…
в 35 градусный точно не надо, проверено
А мне кажется что этот подогрев не спроста… Встроенная в сенсоры температурная компенсация всегда у меня вызывала много вопросов, а тут ребята похоже сделали “по взрослому” как в настоящих ЛА, наверно этот подогрев контролируется программно, отсюда и выдающиеся характеристики по стабильности получили 😃.
а тут ребята похоже сделали “по взрослому” как в настоящих ЛА, наверно этот подогрев контролируется программно, отсюда и выдающиеся характеристики по стабильности получили
аналоговые датчики без компенсации и дабы не плодить танцы с холодильником как в AutoQad - подогрели )))
А мне кажется что этот подогрев не спроста…
При более-менее постоянной низкой температуре проблем не замечал, а вот если из теплой машины вытащить на мороз и сразу лететь, то немного сносит поначалу, но не сильно критично.
Чёй-та тема заглохла…
Я вот с Калманом подружился))) кстати 90% примеров в нете неправильные)))
могу дать подсказку - регулятор (Kalman Gain) практически все рассчитывают неправильно, из-за лени или непонимания рассчёта обратной матрицы, её, точнее 2 формулы рассчёта превращают в одну, чем вызывают проблемы регулировки в реальных случаях, в теоретических (идеальных) условиях работает - практически нет - несколько статей на хабре с той же ошибкой и люди писаются от счастья, что прозрели прочитав)))
так вот скажу - там неправильно…
p.s. кто-то может сказать, что я изучил его ещё на курсах edx, разочарую - курс не дал ничего кроме представления о нём о чём-то как реальном, потом несколько попыток тупо посчитать, но так как я пока не представлю все происходящие процессы в голове (ну уж видно так мозг у меня устроен) формулы остаются для меня просто формулами не имеющими реального смысла… картинка сложилась )))
Да примеры в тырнете скорее правильные, но большинство из них приведены для линейных процессов, чего к сожалению практически нет в жизни. А вот с нелинейными уже сложнее, где нужно проводить линеаризацию модели через частные производные, джакобины (jacobians) или как их там…
Из курса тогда так и не понял мат. сути как получается главный рег. коэф. т.е. kalman gain. Мне тоже нужно что бы на пальцах было понятно, либо в крайнем случае кубиками мозайки могут быть четкие ясные абстракции ))) А разобрался, раскажи всем 😉
P.s. раньше копался с этим примерчиком, так в нем реально поддельный калман с ошибками, т.е. подогнали на результат, а по сути не рабочий)))
www.cs.utexas.edu/~teammco/misc/kalman_filter/
Привет! Давно тебя не видно!!!
Самый прикол в том что оно вроде всё не так и сложно, но на пальцах рассказать как-то пока не могу )))
Короче на реальном железе попробую - тогда может что и расскажу)))
на данный момент просчитываю 3 координаты, 3 скорости, без матрицы поворота и без вектора и матрицы управления…
да и 5 листов в “аналоговом” виде как то в “цифру” переводить влом…
Я расписывал матрицы и смотрел, что в них получается и к чему это приводит считал их по одной тут matrixcalc.org
самая проблема - это ковариации (шум) самого фильтра - тут без бубна никак…
а вот регулятор берётся разный в зависимости, что собрался делать: прогнозировать, фильтровать или сглаживать…