КУК на mems гироскопах
Как думаете стоит делать дальше?
конечно стоит!
и тогда уж добавьте “И” сюда, т.е. сделайте полный ПИД регулятор… это должно добавить стабилности и уменшить болтанку…
“И” составляющая она для длительного воздействия, болтанку должна уменьшить “Д” составляющая.
“И” составляющая она для длительного воздействия, болтанку должна уменьшить “Д” составляющая.
все верно “Д” ускоряет переходные процессы, а “И” как раз помогает в последствии держать систему в равновесии при незначительних отклонениях…
з.ы. Если сказать точнее то “Д” вносит свою значительную лепту (всплеск) в начале переходного процесса и почти не влияет на его завершение, таким образом можно ускорить перходной процес не увиличивая “П” и избежать перерегулирования (болтанки)… а вот “И” это уже стабилизация (компенсация “мелких” отклонений) - поддержка системы в равновесии ближе к концу переходного процесса…
читали доку про ПИД регули на примере сливного бочка? 😃
Да,было дело с бачком))
На этом примере начал немного проникатся тау, а то от наших горе преподов в универе толку было мало.
в общем “И” важный параметр стабилизации системы…
вот легкая коротенькая статейка в помощь pidcontrol.narod.ru
планирую еще вот ету прочитать, все руки не доходят…
Вот тестовое видео с новой прошивкой. Пока только П регулятор, так что поведение схожее с КК. Но зато теперь возможно дописать полноценный ПИД и другие фишки, ресурсов мк еще много. Пока только использовал один таймер на все.
Вот тестовое видео с новой прошивкой. Пока только П регулятор, так что поведение схожее с КК. Но зато теперь возможно дописать полноценный ПИД и другие фишки, ресурсов мк еще много. Пока только использовал один таймер на все.
а в какой cреде разработки под КУК нужно писать?
исходники планируете выкладнвать?
можно сразу на гугл проект завести… быстро найдете соратников по развитию проекта…
- Среда AvrStudio.
- Когда проект будет готовый. Будет новая прошивка и новая плата отличная от КК.
- Соратник есть.
- В 6D мат. операции проходят с плавающей точкой, что в отличии от КК с целочисленым мат. апаратом позволяет точнее просчитывать сигналы управления;
Вот это сразу насторожило. Для AVR плавающая точка не есть хорошо. Это раз. С целочисленной арифметикой можно получить результат не хуже плавающей точки. А иногда и лучше. Поначалу у некоторых разрыв шаблона случается, но гуглим “целочисленная арифметика масштаб” и все станет понятно. Это стало быть два.
Могу с этим делом помочь. Если сам вспомню 😃
Согласен что в авр операции с плавающей точкой не есть хорошо, потому как занимает наверно раз в пять больше тактов процессора чем целочисленные операции. Могу еще добавить, что и с делением в авр туго, нет у нее встроенной функции деления, которая тоже емулируется через ж*.
Но я старался написать код так, что бы все операции вычисления заканчивались вовремя. Распределил функции по времени что бы одни не налазили на другие.
А по поводу получения лучших результатов с целочисленной математикой не совсем согласен, скажем так, мнение может расходится смотря что вас на данный момент больше интересует - быстродействие или точность.
КК - полностью на целочисленной математике.
Мультивий - математики с точкой.
Не лучше ли сразу ваять код на 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гц). Этого более чем достаточно. Если у вас время цикла меньше с флоатами, снимаю шляпу 😃 Вероятно что и менше, так как в вии фенек всяких дохера (типа експо ролл/питч) + ПИД регуль полный.