Создание собственной системы стабилизации
Я использую следующий алгоритм:
Углы с кватерионов получаю так:
Но значения углов скачут от фанаря. Что я не так делаю?
алгоритм с библиотеки 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-ка?), попробуй тоже самое в Акро чисто на гирах…
Да, ЛСМка, но аксель здесь не при чём, удержание чисто на шарпе. смешивание с акселем отключил иначе плывёт сильнее.
Не я имел ввиду аппарат по крену и тангажу дёрганый какой-то…
Не я имел ввиду аппарат по крену и тангажу дёрганый какой-то…
)))) Неее, Это я его так дёргаю чтоб показать каки он держит высоту.
Аксель бывает плавно уводит горизонт на несколько градусов, эта даа…((
Кто то работал с компасом HMC5883L который подключен через MPU6050 (через AUX)? Что то не выходит вычитать данные с компаса.
Тут вопрос: а зачем? компас и МПУ можно на одну и2ц прикрутить. А вот МПУ6000 через SPI и компас через МПУ - вот это была бы песня! Вы к МПУ6000 знаете как компас транзитом прикрутить?