Создание собственной системы стабилизации
Да к тому же он в дополнительном коде выдаёт показания, т.е. при 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.
Т.е. получается что один из пары процев должен тупо ждать второй…
Как то не срастается в голове, может чего туплю ???
Т.е. получается что один из пары процев должен тупо ждать второй…
Как то не срастается в голове, может чего туплю ???
я не про синхронизацию говорил, а оптимизацию - в прерывании должо быть как можно меньше кода, основной код вне прерываний должен быть.
также… если есть возможность и данная ф-ция необходима - почему бы не поменять процессор? конечно если это делать уже на готовом устройстве а не на прототипе - то такое непокатит
Выгоду в увеличении числа корпусов вижу если они дешевые как mega.
Вообще здесь в ветке кто то уже поднимал эту тему,
заманчиво было бы сделать распределенную систему у которой каждая mega могла бы обрабатывать медленную периферию (GPS, PPM приемника, датчики наконец) а одна собирать данные в “кучу” о шустро с ними разбираться пр помощи всяких там кватернионов, DCM, и т.д.
Один из перспективных путей вообще использовать AVR, да чот пока не выходит…
Т.е. плодить кучу микросхем, увеличивая массу и габариты, глюки и т.п. при дешевых и более мощных STM-ах? уж лучше тогда 8-ми ядерный Propeller Parallax, но он дороже чем ARM, а фунционал сопоставим с атмегой…
Это извечная делема многозадачности и параллеризма обработки процессов реального времени. (windows, CUDA, и т.д.). Хочется конечно сделать что то оригинальное, свое, улучшить так сказать… Но приходишь к выводу зачастую, что все давно уже придумано.
А параллельное вычисление на разных ядрах (для коптеров) всеж может дать выигрыш, но видать не на AVR, это уже философия…
Кстати 32-х разрядах, хорошо, но ! Если в перспективе захочется отойти от шумных и медленных MEMS в пользу скажем стабилизации по обработке видео с камеры (попытки в сети встречал где то) то их кажущаяся избыточная производительность растает как снег. Вот и встанет тогда вопрос о многоядерности…
Вот подмывает, развить одну идею, подсказанную Gapey, IMU соединить с основной платой мягким шлейфом(так сделано в NAZE если не ошибаюсь), а саму плату IMU посадить на основную на толстый двухсторонний скотч, по идее убьются ненужные вибрации и меньше места будет занимать разъём (разъёмы), но побаиваюсь соединений разъёмов со шлейфом, не хотелось бы в полёте “потерять” все датчики разом? пока пороюсь в загашнике что у меня на эту тему есть…
Пока ковырялся со своим акселем заметил,что не всегда более мягкий подвес дает меньшие шумы, зачастую наоборот…
Без экспериментов не обойтись видимо.
Вот подмывает, развить одну идею, подсказанную Gapey
То что уйдут вибрации на это надежды мало, масса то будет совсем маленькая, шлейфы конечно паять сразу к плате стремно, без какого-либо армирования, особенно если изоляция жесткая. Я припаивал к иму сразу разъем и втыкал в плату, так иму благополучно кочевал с шелда на шилд для меги. Сделал фиксирующую скобу для иму чтобы не вылетела из разъема и не потерялась в случае чего. Еще опасность шлейфа если плата не защищена боксом, то при краше летящие ошметки иногда их срывают, но это харкорынй варинт событий. Сейчас когда перешел на F104 проц и шлейфов стало больше буду думать над каким-то коробом.
Кто то работал с компасом HMC5883L который подключен через MPU6050 (через AUX)? Что то не выходит вычитать данные с компаса.
Полетал на бреющем полёте с удержанием высоты по шарповскому дальномеру
стабилизация исключительно по дальномеру БЕЗ акселя сонара и пр.
Видно как местами вихри снега попадают в луч дальномера, и квадра как бы подпрыгивает на них.
Прошу прощения за качество съёмки, у на -28 теплый воздух от капота немного искажает.
Создалось впечатление что аксель чудит(LSM-ка?), попробуй тоже самое в Акро чисто на гирах…
Создалось впечатление что аксель чудит(LSM-ка?), попробуй тоже самое в Акро чисто на гирах…
Да, ЛСМка, но аксель здесь не при чём, удержание чисто на шарпе. смешивание с акселем отключил иначе плывёт сильнее.
Не я имел ввиду аппарат по крену и тангажу дёрганый какой-то…
Не я имел ввиду аппарат по крену и тангажу дёрганый какой-то…
)))) Неее, Это я его так дёргаю чтоб показать каки он держит высоту.
Аксель бывает плавно уводит горизонт на несколько градусов, эта даа…((