Создание собственной системы стабилизации
в коде должно встретится что-то на подобии
time=micros();
Dt=time-oldtime;
oldtime=time;
это и есть расчёт dt потом уже его делим (зависит от того в чём запущен отсчёт) чтобы получить секунды…
а recipnorm() это встроенная функция матлаба ?
на сколько вижу из приведённого вами кусочка кода это float переменная
Это, насколько я понимаю, уже готовый фильтр на квартенионах, а что на входе?
На входе данные с гиро и акселя.
recipNorm да это переменная.
не ну понятно, вопрос какие, для муратовских, и если соблюсти условия что я приводил выше, то данные с гир будут выглядеть так:
gyroXrate = (gyroXadc-gyroZeroX)*2.4; где gyroXadc - цифирки снятые с АЦП, gyroZeroX нулевые показания гиры с АЦП, 2.4 - коэффициент приведения к градусам в секунду из показаний АЦП, а какой аксель я не знаю…
С муратовскими гирами не всё так просто, у них 0.67мВ/град/сек и 0 у них 1.35В, 10-ти битного АЦП маловато, по сей причине надо для начала на Aref АВРки подать 1.65В (не забыв analogReference(EXTERNAL); сделать) - это максимум что могут выдать гиры, тоесть 1.65В будет равно 1024 для АЦП и тогда уже пытатся считывать с них какую-то информацию 😃
Сергей спасибо за поддержку!
Как считаете, у меня сейчас аксель (на пробу взял) с диапазоном 1G=64 единицы, дубовый видимо да?
Можно наверно с ним даже не пробовать что либо получить дееспособное?
у меня сейчас аксель
маркировку пожалуйста…
MMA7455
включайте в 10-ти битном режиме иначе из-за шума самого датчика показаний толком не видно будет…
так себе датчик, только большие углы покажет…
10-битный в нем только при шкале 8G работает (шило на мыло) , короче ясно - мягко говоря не очень, но попробую конечно для начала хоть что то нащупать…
Да к тому же он в дополнительном коде выдаёт показания, т.е. при 8-ми битном режиме в char забирать надо, а потом с ней мучатся 😦 , а почему в другую переменную не запихнуть, всё просто- знак (±)теряется 😦
Мне б сначала хоть какой нибудь результат стабилизации получить, зацепиться за тему, уж очень хочу свой понятный от А до Я код написать без коммерческой универсальности, просто чтоб летало…
Чужой код, для меня , читать а тем более править трудновато, а хочется чтоб увлечение имело какое то развитие в перспективе, из-за этого и связался… (многие скажут еще один велосипед изобретает), хочу и все…
Угол_Х слева равенства это искомое значение (отклонение ЛА) Угол_Х внутри скобок это предыдущее значение гиры за время цикла опроса dT?
нет, это уже обновлённое значение угла по ДУС(датчик угловых скоростей, гироскоп - неправильное название для МЕМС ДУС,импортный жаргонизм или упрощенное представлние), высчитаное в цикле по первой формуле.
dT в условных единицах ? (видимо мСек., или как оно вообще там реализовано)
в единицах приведённых к весу разряда датчика, т.е. если вес разряда дус 1рад/с, то dt в секундах, если 0,0001 рад/с, то dt в миллисекундах.
0.8 и 0.2 - что это?
вес влияния датчика на итоговое значение угла.
и с акселя данные уже как то обсчитанные или “голые”?
Аксель даёт вектор суммы действующих ускорений, чтобы получить угол надо посчитать обратную тригонометрию от координат вектора. На АВРе обычны приближенные вычисления…
Александр, а можете сформулировать перспективность 32-х разрядов для данной задачи или если хотите тупиковось AVR?
Если Вам интересно выжимать такты из АВР и Вы хорошо знакомы с методами приближенных или алгоритмами быстрых вычислений, то вперёд - сделаете стабильно летающую платформу с минимумом доп функций, дальнейший рост функций только добавлением доп процов. И по Вашим же словам у Вас пока нет представления опринцыпах работы подобных систем, посему будет лучше сосредоточится над решением вопросов связанных с системой управления, а не над оптимизацией кода. Т.е. АВР свяжет по рукам и ногам ваши эксперименты…
для МЕМС
Будешь смеяться Murata пьезоэлектрические …
Будешь смеяться Murata пьезоэлектрические …
Не буду ), но сути это не меняет, мериют они всё равно угловуые скорости, а не угол относительно установленого пложения.
Я использую следующий алгоритм:
Углы с кватерионов получаю так:
Но значения углов скачут от фанаря. Что я не так делаю?
алгоритм с библиотеки FreeIMU… как раз с ней 2-й день бодаюсь… сейчас наконец то вроде норм получатся стало - присутствует небольшой дрейф(туда а птом обратно) в +/-10 град по яв и по +/-2 градуса по питч и ролл - чую нужно подбирать коэффициенты.
Вчера долго мучался как раз таки с вращением по всем осям…
- необходимо определится по направлением осей
- обязательно калибровать аксель и компас… у фабио сейчас есть вполне норм. ГУИ для калибровки.
кстати время расчета квантерионов ~2100мкс, углов ~2500мкс (это вкупе с чтением датчиков), проц хмега на 32МГц работает, вроде вполне норм время для калмана получилось… думаю если удастся внедрить в мультивий то время цикла не более 4000 будет.
Во ещё одно доказательство преимущества ARM, у меня цикл на усЁ максимум 1600 на F103 😃
кстати время расчета квантерионов ~2100мкс, углов ~2500мкс (это вкупе с чтением датчиков), проц хмега на 32МГц работает, вроде вполне норм время для калмана получилось… думаю если удастся внедрить в мультивий то время цикла не более 4000 будет.
У меня дополняющий (комплементарный) фильтр на СТМ32Ф103 72Мгц 250~300 мкс цикл ДУС с периодом 400Гц и также цикл акселя с компасом 270~325 мкс с периодом 50Гц, и того занятость проца ~14%.
Во ещё одно доказательство преимущества ARM
ну во первых… то что у меня сейчас - портировано на скорую руку - вполне можно обеспечить меньшее время…
во вторых - никто не мешает множитель фапч поднять до 3-х и работать на 48МГц.
с комплементарным родным виевским у меня на хмеге цикл на все 2500
и вообще, как бы не большая часть этого времени - это чтение датчиков по и2с интерфейсу…
могу даже ради интереса посмотреть время чисто вычислений…
По поводу многопроцессорности системы.
Пробовал связать два AVRa по SPI, но у обеих были аппаратные прерывания от периферии, ломал голову – ни как не выходит…
Т.е. если “мастер” начинает просить данные у “слейва” а тот в это время занят (прерыванием) происходит затык.
Есть у кого мысли на этот счет, наработки, идеи ?
могу даже ради интереса посмотреть время чисто вычислений…
посмотрел… как я и думал опрос чисто датчиков занимает больше половины времени… чисто вычисления сейчас 980-1006 микросекунд -> опрос датчиков (аксель гира и компас) - 1100мкс
Есть у кого мысли на этот счет, наработки, идеи ?
хм… странно…
ну во первых… оптимизируйте прерывания
во вторых, опрос по спи насколько часто и объемно?
в третьих… какие авр и что за цель? просто например в хмеге можно организовать DMA канал SPI интерфейса с оперативкой или любой другой периферией + эвент система - проц не участвует вообще и занимается своими делами
[QUOTE=
хм… странно…
ну во первых… оптимизируйте прерывания
[/QUOTE]
В том то и дело, что не Xmega, прерывания на обоих чипах не синхронизируешь, буферный регистр сдвига (SPI) сбрасывается у “слейва” как только с чипа снимается сигнал выборки кристалла CS.
Т.е. получается что один из пары процев должен тупо ждать второй…
Как то не срастается в голове, может чего туплю ???
Т.е. получается что один из пары процев должен тупо ждать второй…
Как то не срастается в голове, может чего туплю ???
я не про синхронизацию говорил, а оптимизацию - в прерывании должо быть как можно меньше кода, основной код вне прерываний должен быть.
также… если есть возможность и данная ф-ция необходима - почему бы не поменять процессор? конечно если это делать уже на готовом устройстве а не на прототипе - то такое непокатит