КУК на mems гироскопах

morion15

Да,было дело с бачком))
На этом примере начал немного проникатся тау, а то от наших горе преподов в универе толку было мало.

mahowik

в общем “И” важный параметр стабилизации системы…
вот легкая коротенькая статейка в помощь pidcontrol.narod.ru

планирую еще вот ету прочитать, все руки не доходят…

morion15

Вот тестовое видео с новой прошивкой. Пока только П регулятор, так что поведение схожее с КК. Но зато теперь возможно дописать полноценный ПИД и другие фишки, ресурсов мк еще много. Пока только использовал один таймер на все.

www.youtube.com/watch?v=D5F2RGA8y2A

mahowik
morion15:

Вот тестовое видео с новой прошивкой. Пока только П регулятор, так что поведение схожее с КК. Но зато теперь возможно дописать полноценный ПИД и другие фишки, ресурсов мк еще много. Пока только использовал один таймер на все.

а в какой cреде разработки под КУК нужно писать?
исходники планируете выкладнвать?
можно сразу на гугл проект завести… быстро найдете соратников по развитию проекта…

morion15
  1. Среда AvrStudio.
  2. Когда проект будет готовый. Будет новая прошивка и новая плата отличная от КК.
  3. Соратник есть.
iBat
morion15:
  • В 6D мат. операции проходят с плавающей точкой, что в отличии от КК с целочисленым мат. апаратом позволяет точнее просчитывать сигналы управления;

Вот это сразу насторожило. Для AVR плавающая точка не есть хорошо. Это раз. С целочисленной арифметикой можно получить результат не хуже плавающей точки. А иногда и лучше. Поначалу у некоторых разрыв шаблона случается, но гуглим “целочисленная арифметика масштаб” и все станет понятно. Это стало быть два.
Могу с этим делом помочь. Если сам вспомню 😃

morion15

Согласен что в авр операции с плавающей точкой не есть хорошо, потому как занимает наверно раз в пять больше тактов процессора чем целочисленные операции. Могу еще добавить, что и с делением в авр туго, нет у нее встроенной функции деления, которая тоже емулируется через ж*.
Но я старался написать код так, что бы все операции вычисления заканчивались вовремя. Распределил функции по времени что бы одни не налазили на другие.
А по поводу получения лучших результатов с целочисленной математикой не совсем согласен, скажем так, мнение может расходится смотря что вас на данный момент больше интересует - быстродействие или точность.
КК - полностью на целочисленной математике.
Мультивий - математики с точкой.

Covax

Не лучше ли сразу ваять код на ARM процессорах? Это был бы прорыв всетаки.

morion15

Прорыв, для меня так точно:) Стм я еще только учу, и тогда проект затянулся бы надолго.
Но я себе не ставил задач подцепить в проект аксель, жпс, бародатчик…Сейчас это будет улучшеный КК. И с этой задачей вполне может справится этот же мк. Зачем применять космический корабль что бы летать на километр в магазин, это бессмысленно(с).
Ну а если будет уже отлаженный алгоритм на авр, потом его будет проще перенести на арм если станет задача еще что то добавить к функционалу. Скорее всего аксель, но тогда уже и так есть замечательные проекты такие как СС и мультивий.

Gapey

если человек знает AVR и незнает ARM , то ему гораздо проще “извратиться” на том что он знает , чем изучать новый камень …
а поповоду AVR , я уже высказывал мысль по поводу располовинивания проекта … те датчики вешаются на 328 мегу , которую можно легко разогнать до 24 Мгц , а с внешним осцилятором и еще больше …
а все остальное на вторую мегу/ардуину которая уже занимается приемником , моторами , логами , прочими интерфейсами …

Covax

Да будь мне 22 я бы все камни мира бы изучил, а так только драгоценные и полудрагоценные знаю 😦 Чувствую Роман скорее сделает порт на стм32 и кука и мультивия 😃

morion15
Gapey:

датчики вешаются на 328 мегу , которую можно легко разогнать до 24 Мгц , а с внешним осцилятором и еще больше …
а все остальное на вторую мегу/ардуину которая уже занимается приемником , моторами , логами , прочими интерфейсами …

Так, если не ошибаюсь, реализован проект в руссоКоптере на двух мк.
Когда делал курсовой проект на 3 курсе, разгонял 32мегу до 26.6 МГц))) Проект заключался в выводе картинки с камеры телефона на дисплей ls020. Камера и дисплей были выдраны из сименса сх65:)

Gapey

на руссокоптере все реализовано на 644 меге на 20мгц … вторая мега ставится только для подключения спектрумовских сателитов …

решение с распилом проекта пока только в стадии реализации , в проекте Опенпилот … но там все совсем повзрослому … в окончательном варианте датчики будут висеть на STM32F2xx на 120 мгц притом аналоговые и на отдельном АЦП … дальше по SPI на второй проц STM32F1xx … но когда это все допишут - ХЗ …

morion15

Выбор аналоговых датчиков обусловлен тем что I2C часто падает? Или я не прав.

Gapey

больше качеством самих датчиков … да и качеством АЦП в цифровых датчиках …
500 гиры инвенсенса одни из лучших … лучше только у аналоговых девиц , но они стоят неприлично дорого и паять их нужно РАКОМ …
если I2C использовать по назначению , то обычно ничего не падает …
а вот когда на неё вешают силовые исполнительные устройства ( регули ) тут уже все зависит от погоды на марсе …

mahowik
morion15:

Мультивий - математики с точкой.

кто вам такое сказал?! 😃 там 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
morion15

Узрите же:
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;

mahowik
  1. это не последняя дев. прошивка.
  2. ИМУ это для стаб мода. В акро моде (только гира) только целочисленные вычисления. При вкл. стаб. мода цикл растет всего на 600-800мкс в случае с акселем, и на 1000-1200мкс в случае с акселем и магнетометром.
  3. Если на борту толко гира, то полное время цикла 1700мкс (~580гц). Этого более чем достаточно. Если у вас время цикла меньше с флоатами, снимаю шляпу 😃 Вероятно что и менше, так как в вии фенек всяких дохера (типа експо ролл/питч) + ПИД регуль полный.
morion15

Имхо частота 580Гц для акро мода избыточная, скажем так, что двигатель не будет успевать реагировать на команды изменения с такой частотой. Оптимальную частоту можно рассчитать зная постоянную времени моторновинтовой установки, но думаю этим никто в мультиВие не занимался.
Я реализовал сигнал управления драйверами 50Гц, что как показали испытания вполне достаточно:)

ПИД реализован тоже только как целочисленный?

mahowik
morion15:

Имхо частота 580Гц для акро мода избыточная, скажем так, что двигатель не будет успевать реагировать на команды изменения с такой частотой. Оптимальную частоту можно рассчитать зная постоянную времени моторновинтовой установки, но думаю этим никто в мультиВие не занимался. Я реализовал сигнал управления драйверами 50Гц, что как показали испытания вполне достаточно

я тоже так думал пока, не насмотрелся видео коптеров с высоким PWM…
также могу сказать из практики что акро вии мега плавен и стабилен (сравнимо с платформами на ARM) + позволяет широкий диаппазон пид-ов + проверен временем…
даже наберусь смелости предложить портировать его в КУК 😃

static.rcgroups.net/…/a3627948-90-freq.jpg?d=12910…

morion15:

ПИД реализован тоже только как целочисленный?

да

morion15

Мега стабилен из-за наличия ПИДа, что позволяет настроить аппарат на максимальное быстродействие без перерегулирования. Если код портировать в КК, то плату все равно придется переделывать, потому что в КК порты для связи с ПК заняты что бы иметь возможность настроить ПИД. К тому же, у гир КК по ДШ частота изменения сигнала 50Гц, и даже если вы повысите ппм на драйвера толку не будет, так как управляющий сигнал будет изменятся только с частотой изменения данных с гироскопов.
В принцыпе этим я сейчас и занимаюсь, улучшаю КК дабавляя в него ПИД и другие функции и заменяю пьезо гироскоп на мемс.