КУК на mems гироскопах
Согласен что в авр операции с плавающей точкой не есть хорошо, потому как занимает наверно раз в пять больше тактов процессора чем целочисленные операции. Могу еще добавить, что и с делением в авр туго, нет у нее встроенной функции деления, которая тоже емулируется через ж*.
Но я старался написать код так, что бы все операции вычисления заканчивались вовремя. Распределил функции по времени что бы одни не налазили на другие.
А по поводу получения лучших результатов с целочисленной математикой не совсем согласен, скажем так, мнение может расходится смотря что вас на данный момент больше интересует - быстродействие или точность.
КК - полностью на целочисленной математике.
Мультивий - математики с точкой.
Не лучше ли сразу ваять код на ARM процессорах? Это был бы прорыв всетаки.
Прорыв, для меня так точно:) Стм я еще только учу, и тогда проект затянулся бы надолго.
Но я себе не ставил задач подцепить в проект аксель, жпс, бародатчик…Сейчас это будет улучшеный КК. И с этой задачей вполне может справится этот же мк. Зачем применять космический корабль что бы летать на километр в магазин, это бессмысленно(с).
Ну а если будет уже отлаженный алгоритм на авр, потом его будет проще перенести на арм если станет задача еще что то добавить к функционалу. Скорее всего аксель, но тогда уже и так есть замечательные проекты такие как СС и мультивий.
если человек знает AVR и незнает ARM , то ему гораздо проще “извратиться” на том что он знает , чем изучать новый камень …
а поповоду AVR , я уже высказывал мысль по поводу располовинивания проекта … те датчики вешаются на 328 мегу , которую можно легко разогнать до 24 Мгц , а с внешним осцилятором и еще больше …
а все остальное на вторую мегу/ардуину которая уже занимается приемником , моторами , логами , прочими интерфейсами …
Да будь мне 22 я бы все камни мира бы изучил, а так только драгоценные и полудрагоценные знаю 😦 Чувствую Роман скорее сделает порт на стм32 и кука и мультивия 😃
датчики вешаются на 328 мегу , которую можно легко разогнать до 24 Мгц , а с внешним осцилятором и еще больше …
а все остальное на вторую мегу/ардуину которая уже занимается приемником , моторами , логами , прочими интерфейсами …
Так, если не ошибаюсь, реализован проект в руссоКоптере на двух мк.
Когда делал курсовой проект на 3 курсе, разгонял 32мегу до 26.6 МГц))) Проект заключался в выводе картинки с камеры телефона на дисплей ls020. Камера и дисплей были выдраны из сименса сх65:)
на руссокоптере все реализовано на 644 меге на 20мгц … вторая мега ставится только для подключения спектрумовских сателитов …
решение с распилом проекта пока только в стадии реализации , в проекте Опенпилот … но там все совсем повзрослому … в окончательном варианте датчики будут висеть на STM32F2xx на 120 мгц притом аналоговые и на отдельном АЦП … дальше по SPI на второй проц STM32F1xx … но когда это все допишут - ХЗ …
Выбор аналоговых датчиков обусловлен тем что I2C часто падает? Или я не прав.
больше качеством самих датчиков … да и качеством АЦП в цифровых датчиках …
500 гиры инвенсенса одни из лучших … лучше только у аналоговых девиц , но они стоят неприлично дорого и паять их нужно РАКОМ …
если I2C использовать по назначению , то обычно ничего не падает …
а вот когда на неё вешают силовые исполнительные устройства ( регули ) тут уже все зависит от погоды на марсе …
Мультивий - математики с точкой.
кто вам такое сказал?! 😃 там 99% операций целочисленных! АлексВпариже (основной разработчик) очень следит за быстродействием!
code.google.com/p/multiwii/source/…/README.txt
- avoid float numbers
в вии не то что на флоатах экономят, там даже каждую 32бит целочисленную операцию Алекс со скрипом позволяет 😃
пример из последней прошивки:
if (abs(deltaSum)<640) DTerm = (deltaSum*dynD8[axis])>>5; //16 bits is needed for calculation 640*50 = 32000 16 bits is ok for result
else DTerm = ((int32_t)deltaSum*dynD8[axis])>>5; //32 bits is needed for calculation
Узрите же:
1)
i2c_BMP085_CompensatedSensor();
altitude = (1.0 - pow(float(pressure)/101325.0, 0.190295)) * 443300 - altitudeZero; // altitude in decimeter from starting point
if ( abs(altitude-altitudeSmooth) < 100 ) //avoid altitude spike
altitudeSmooth = (altitudeSmooth*7+altitude+4)/8;
2) И самый главный алгоритм! Боюсь представить сколько тактов он занимает)))
// ************************************
// simplified IMU based on Kalman Filter
void getEstimatedAttitude(){
int8_t i;
float R;
static float RxEst = 0; // init acc in stable mode
static float RyEst = 0;
static float RzEst = 1;
static float Axz,Ayz; //angles between projection of R on XZ/YZ plane and Z axis (in Radian)
float RxGyro,RyGyro,RzGyro; //R obtained from last estimated value and gyro movement
uint8_t wGyro = 100; // gyro weight/smooting factor
static float invW = 1.0/(1 + 100);
float gyroFactor;
float a,b;
static uint8_t small_angle=1;
static uint16_t tCurrent=0,tPrevious=0;
uint16_t deltaTime;
float magX;
float magY;
float cos_roll = 1;
float sin_roll = 0;
float cos_pitch = 1;
float sin_pitch = 0;
…
- это не последняя дев. прошивка.
- ИМУ это для стаб мода. В акро моде (только гира) только целочисленные вычисления. При вкл. стаб. мода цикл растет всего на 600-800мкс в случае с акселем, и на 1000-1200мкс в случае с акселем и магнетометром.
- Если на борту толко гира, то полное время цикла 1700мкс (~580гц). Этого более чем достаточно. Если у вас время цикла меньше с флоатами, снимаю шляпу 😃 Вероятно что и менше, так как в вии фенек всяких дохера (типа експо ролл/питч) + ПИД регуль полный.
Имхо частота 580Гц для акро мода избыточная, скажем так, что двигатель не будет успевать реагировать на команды изменения с такой частотой. Оптимальную частоту можно рассчитать зная постоянную времени моторновинтовой установки, но думаю этим никто в мультиВие не занимался.
Я реализовал сигнал управления драйверами 50Гц, что как показали испытания вполне достаточно:)
ПИД реализован тоже только как целочисленный?
Имхо частота 580Гц для акро мода избыточная, скажем так, что двигатель не будет успевать реагировать на команды изменения с такой частотой. Оптимальную частоту можно рассчитать зная постоянную времени моторновинтовой установки, но думаю этим никто в мультиВие не занимался. Я реализовал сигнал управления драйверами 50Гц, что как показали испытания вполне достаточно
я тоже так думал пока, не насмотрелся видео коптеров с высоким PWM…
также могу сказать из практики что акро вии мега плавен и стабилен (сравнимо с платформами на ARM) + позволяет широкий диаппазон пид-ов + проверен временем…
даже наберусь смелости предложить портировать его в КУК 😃
static.rcgroups.net/…/a3627948-90-freq.jpg?d=12910…
ПИД реализован тоже только как целочисленный?
да
Мега стабилен из-за наличия ПИДа, что позволяет настроить аппарат на максимальное быстродействие без перерегулирования. Если код портировать в КК, то плату все равно придется переделывать, потому что в КК порты для связи с ПК заняты что бы иметь возможность настроить ПИД. К тому же, у гир КК по ДШ частота изменения сигнала 50Гц, и даже если вы повысите ппм на драйвера толку не будет, так как управляющий сигнал будет изменятся только с частотой изменения данных с гироскопов.
В принцыпе этим я сейчас и занимаюсь, улучшаю КК дабавляя в него ПИД и другие функции и заменяю пьезо гироскоп на мемс.
Мега стабилен из-за наличия ПИДа, что позволяет настроить аппарат на максимальное быстродействие без перерегулирования. Если код портировать в КК, то плату все равно придется переделывать, потому что в КК порты для связи с ПК заняты что бы иметь возможность настроить ПИД. К тому же, у гир КК по ДШ частота изменения сигнала 50Гц, и даже если вы повысите ппм на драйвера толку не будет, так как управляющий сигнал будет изменятся только с частотой изменения данных с гироскопов. В принцыпе этим я сейчас и занимаюсь, улучшаю КК дабавляя в него ПИД и другие функции и заменяю пьезо гироскоп на мемс.
Ну с МЕМС однозначно надо будет повышать частоту обработки, либо хотябы не понижать ее вычислениями с плавающей запятой…
Стабилизация зависит не только от ПИД регуля и вычислений в флоатах, но и частоты дискретизации получения данных + скорости их обработки… И даже если частота данных с гиры 50гц, то мин частота обработки этих данных должна быть не мение 100гц (10мс), лучше 200гц… Чем меньше время цикла, тем выше частота дискретизации и тем выше точность расчетов как в ИМУ так и в ПИД регуле. В частоности “И” высчитывается суммированием в цикле и тут чем выше частота, тем точнее результат стабилизации. Ну и сами понимаете, даже если считать во флоатах, то что это даст, если данные быстрых изменений системы будут проглатываться, ошибки циклических вычислений будут быстро расти.
В общем не зря тут матерые перцы говорили: хош стабильности и плавности - повышай частоту. Так же это одна из причин тотального перехода на АРМы…
Проект преходит на stm32. Первая версия акселерометр+гироскоп планируется выйти до НГ, подержка трикоптера и квадро, обычный ПИД, прошивка и общение с ПК будет без стороних девайсов, т.е. all inclusive.
В последующих версия по плану стабилизация подвеса камеры, автонастройка ПИДа/стабилизации на нейронных сетях. Подключил к проекту мега мозк, парня который занимался нейроными сетями с возможностью самобучения.
Сейчас для тестов еще первого алгоритма на плате КК, делаю квадро
Результаты есть? 😃
Есть результаты. Разработана уже вторая версия платки на stmF2. Написал три алгоритма инерциальной системы в частности на кватернионах и матрице косинусов. В каждом алгоритме есть свои плюсы и минусы.
В первой версии юзал два отдельных датчика акселерометра и гироскопа показания были нормальными, после КИХ фильтра 5 порядка показания были очень хорошими. Во второй версии решил применить датчик два в одном LSM с ним пока и возникли проблемы, очень сильно плавает акселерометр.