Создание собственной системы стабилизации
в прерывании просто ставим флаг, что новые данные пришли.
войти в прерывание (потратить такты) изменить бит, выйти из прерывания (потратить такты)?
Если я падаю, то не хотел бы терять управление стиками.
это я утрировано сказал…
Мне китайцы, что-то выслали на замену утеряных ИК датчиков, сегодня пойду забирать - посмотрю что…
войти в прерывание (потратить такты) изменить бит, выйти из прерывания (потратить такты)?
это я утрировано сказал…
Мне китайцы, что-то выслали на замену утеряных ИК датчиков, сегодня пойду забирать - посмотрю что…
а по другому как? постоянно проверять, пришли данные или нет? весеть в цикле ожидания, показанные не придут? тогда на весь цикл будет куча проверок.
что утрированно, я понял, просто пока сложно представить себе такую ситуацию, в которой мне надо было бы от чего-то отказываться.
нашел математику нужно проверять.
А поделитесь ссылкой на математику?
вот возмём простейший - ну да КУК - сидим курим в нопах, пока прерывания с радио не пришло, пришло - запустили основной цикл, а там и чтение гир и перерасчёт выходных шимов, вот чем нравятся аналоговые датчики - они всегда готовы…
если какое-либо прерывание выполняется, то надо обязательно запрещать остальные, придёт прерывание в прерывании, куда вернётся программа после? ей бабушка нашепчет? да билеберда получится, хорошо если в основной цикл, а скорей в прерывании и зациклится - шахид-коптер получится, камикадзе многороторный - только банзай кричать научить надо 😃
вот возмём простейший - ну да КУК - сидим курим в нопах, пока прерывания с радио не пришло, пришло - запустили основной цикл, а там и чтение гир и перерасчёт выходных шимов, вот чем нравятся аналоговые датчики - они всегда готовы…
если какое-либо прерывание выполняется, то надо обязательно запрещать остальные, придёт прерывание в прерывании, куда вернётся программа после? ей бабушка нашепчет? да билеберда получится, хорошо если в основной цикл, а скорей в прерывании и зациклится - шахид-коптер получится, камикадзе многороторный - только банзай кричать научить надо 😃
пока видишь в нопах, твой проц никакой полезной работы не делает. это не есть хорошо.
сидишь в прерывании, пришло другое?! если у пришедшего больший приоритет, ушел в него, вернулся после в старое. если меньший, будет стоять очереди, пока не закончится текущее.
вернулся после в старое
а там каша (как это? - срыв стека) и по кругу из прерывания в прерывание, неважно какой приоритет, если мы сидим в прерывании - никаких прерываний - пускай ждут, а вот ежели пришли два одновременно тогда да - пропускаем старшее - младшее подождёт!
на вас никогда аппарат не бросался? на меня несколько раз уже покушался 😦
а там каша (как это? - срыв стека) и по кругу из прерывания в прерывание, неважно какой приоритет, если мы сидим в прерывании - никаких прерываний - пускай ждут, а вот ежели пришли два одновременно тогда да - пропускаем старшее - младшее подождёт!
на вас никогда аппарат не бросался? на меня несколько раз уже покушался 😦
ну начнем с того что срыв стека - это не типичная ситуация. возникнуть может когда угодно и за нее программисту руки отрывать надо. бросался на самописном ПО или на чужом? если на чужом, тут уж ничего не поделаешь, Вы доверяете свое здоровье кому-то в руки, используя чужую прошивку.
таких нетипичных ситуаций нужно избегать, прерывания тут не при чем, ушли в функцию, а из-за срыва стека вышли из нее в другом месте. так что теперь, все писать одной портянкой, не используя функций вообще?
stm32f3discovery или stm32f4discovery?
CooCox поддерживает f4 из коробки (уже подтвердили выше)… если у вас получилось с stm32f3discovery, то расскажите плз. как… у меня не пашет…
Стучитесь в личку или в аську 260209301 - подскажу. Там все довольно просто, могу даже пример проекта скинуть на F4 или F103
а там каша (как это? - срыв стека) и по кругу из прерывания в прерывание, неважно какой приоритет, если мы сидим в прерывании - никаких прерываний - пускай ждут, а вот ежели пришли два одновременно тогда да - пропускаем старшее - младшее подождёт!
Во первых, не знаю как на STM, а на AVR если вошли в обработчик прерывания, то прерывания автоматом отключаются. Что бы их включить, надо либо завершить обработчик, либо включить руками.
Теперь, если вы не включили прерывания, то по выходу из обработчика, выполнится следующее прерывание которое стоит в очереди.
А вот если включили вручную прерывание посреди обработчика, то может выполнится любое другое прерывание, но по его завершению, работа продолжится. Тут кроется одна большая засада - если по каким либо причинам, у вас много раз произойдет наложение обработчиков, получится Stack Overflow.
Поэтому, прежде чем разрешать прерывания в теле какого либо обработчика, надо 5 раз подумать.
так а я про что, пускай ждут, за пару микросекунд с ними ничего не случится…
Во первых, не знаю как на STM, а на AVR если вошли в обработчик прерывания, то прерывания автоматом отключаются. Что бы их включить, надо либо завершить обработчик, либо включить руками.
Теперь, если вы не включили прерывания, то по выходу из обработчика, выполнится следующее прерывание которое стоит в очереди.
А вот если включили вручную прерывание посреди обработчика, то может выполнится любое другое прерывание, но по его завершению, работа продолжится. Тут кроется одна большая засада - если по каким либо причинам, у вас много раз произойдет наложение обработчиков, получится Stack Overflow.
Поэтому, прежде чем разрешать прерывания в теле какого либо обработчика, надо 5 раз подумать.
на стм одно прерывание может быть вызвано из другого согласно приоритету. чтобы стек не переполнялся, просто надо это учитывать. в раз 10 штук не придут никак.
извечный вопрос - что делать? вместо ифк датчиков прислали 4 пирометра, поругаться или с пирометрами что-нибудь замутить?
Интересное наблюдение. Подключил я к STM32F105 GPS модуль MTK3339. Мудохолся-мудохался, а модуль спутники не находит. И вот однажды в процессе отладки я остановился на точке останова и о чудо, модуль в помещении находи 6 спутником. После запуска программы, GPS буквально за 5сек потерял все спутники.
После запуска программы, GPS буквально за 5сек потерял все спутники.
Ищите источник (паразитный) радиоизлучения на плате… Проблема актуальная, например некоторые видеокамеры при приближении к модулю GPS аналогично глушат сигнал…
Стало лучше после установки дросселя по +. Но все равно после запуска ядра МК теряется часть спутников.
в этом архивчике с экзамплами www.st.com/web/en/catalog/tools/PF257904
у меня только wirish_math из maple выдрано…
в библиотеках CMSIS точно есть arm_math.h если что тоже есть…
За ссылочки спасибо, но там только заголовочный файл с объявленниями, а вот где бы посмотреть реализацию…
Там все довольно просто, могу даже пример проекта скинуть на F4 или F103
я писал про F30х (в Coocox поддержки нет по умолчанию), а вы говорите про F4 и F1…
на пред-й странице я писал и выкладывал ссылку шаблон демо проекта под F3, но debug не пашет там…
но там только заголовочный файл с объявленниями, а вот где бы посмотреть реализацию…
поиском воспользуйтесь 😉
например функция arm_mat_add_f32
arm_status arm_mat_add_f32(
const arm_matrix_instance_f32 * pSrcA,
const arm_matrix_instance_f32 * pSrcB,
arm_matrix_instance_f32 * pDst);
путь в архиве: \STM32F4-Discovery_FW_V1.1.0\Libraries\CMSIS\DSP_Lib\Source\MatrixFunctions\arm_mat_add_f32.c
Стало лучше после установки дросселя по +. Но все равно
Какая плата? Если неудачная топология разводки, то поможет полное экранирование (как у радиомодулей)…
переделал корректор ИНС как у Тома Пикке, code.google.com/p/gluonpilot/...e_quaternion.c
а по чем там X,Y корректится? гпс? optflow?
вся математика алгебраически оптимизирована, можешь на АВР попробовать
глянул… не потянет авр-ка похоже…
Счас горизонт лучше, но из-за наличия интегральной составляющей присутствует медленная раскачка.
Если ты про конечный пид регуль, то есть парочка рецептов:
- убери I в ноль, если станет заметно стабильнее, то подними его на мин., напару единиц, так что бы не влияло на горизонт и не вводило в раскачку…
- если у тебя классический пид регуль с углом из ИМУ на входе, то убедись что у тебя правильный знак на Д-часть и она задает противодействие (П+И)-частям. т.е. если на входе угол, то Д-часть это по сути угловая скорость, принимая что требуемое/заданное положение/угол постоянно на коротком промежутке времени… т.е. Д-часть должна вводить заблаговременное торможение системы, а не ускорение… Вообще имеют право на жизнь П+И+Д и П+И-Д регули, но первый вариант для коптеров не катит. Уже (не помню кто) проверял на форуме. Результат П+И+Д: раскачка и перевертыши…
Если со знаками в Д-части все ок, то попробый увеличить Дк, т.е. силу противодействия/торможения к требуемому/заданному положению…
Вот коротко и клева написано про пидЫ pidcontrol.narod.ru - Не помогло? Тогда далее 😃
Удали Д часть из ПИД регуля и введи ПД (со знаком минус!) по скорости с ДУС. Собственно это секрет стабильности вия в акро и стаб/level режимах.
Т.е. получится:
УВ(упр. воздействие) = ПИ(угол из ИМУ на входе) - ПД(угловая скорость гиры)
Для ПД (по скорости с гиры) есть парочка нюансов:
- данные с гиры надо слегка усреднить ~20 герц
- Д-часть, т.е. дифференциал угловой скорости - это по сути угловое ускорение, которое может начать шуметь, потому его тож надо усреднить чутка. В вие усредняются три последних дифф-а (median filter вроде). Если брать 4-ре, то выходит по плавности совсем “подводная лодка” 😃 и убирает мелкие осцилляции на концах лучей. У меня в прошивах - это KILL_SMALL_OSCILLATIONS. ФПВэшники рады 😃
/* It should help to remove small oscillations produced by D-part of main PID regulator.
* It's also usefull to improve vibro-protection in general, even stability for video cameras (info from feedback ot real user).
* Note: theoretically it increases D-part for 20-30% and you will need to increase acro P coef. accordingly.
* E.g. P roll/pitch was 5.2 and should be changed to 6-6.5
*/
//#define KILL_SMALL_OSCILLATIONS
Вот код ПД-части по гире:
PTerm -= ((int32_t)gyroData[axis]*dynP8[axis])>>6; // 32 bits is needed for calculation
delta = gyroData[axis] - lastGyro[axis]; // 16 bits is ok here, the dif between 2 consecutive gyro reads is limited to 800
lastGyro[axis] = gyroData[axis];
deltaSum = delta1[axis]+delta2[axis]+delta;
delta2[axis] = delta1[axis];
delta1[axis] = delta;
DTerm = ((int32_t)deltaSum*dynD8[axis])>>5; // 32 bits is needed for calculation
axisPID[axis] = PTerm + ITerm - DTerm;
По настройке:
а) обнули ПИ по углу… по сути отруби результат своей ИМУ вращалки 😃
б) натяни ПД так (вплоть до появления перекомпенсации/осцилляций), чтобы в руках коптер существенно сопротивляся наклонам на газу висения (т.е. 40-60%)… потом уменьшай ПД на 20…30%, что бы не вводить в перекомпенсацию…
в) подымай П (по углу) на желаемую скорость реакции стиков… + добавь немного И, сосем чутка…
Должно помочь 😉
поцарапал стены, поругался с женой
моя за стены не бьет, а вот за измену ей с коптером ругается! 😃
Гдето видел OpticFlow за 50 баксов и не могу вспонить где
вот вариант красивый, но дороговато:
pixhawk.ethz.ch/px4/modules/px4flow
store.diydrones.com/ProductDetails.asp?ProductCode…
а по чем там X,Y корректится? гпс?
Скажите а ЧТО можно скорректировать по ГПС ? если точность при н.у. +/- 10 метров ?
Скажите а ЧТО можно скорректировать по ГПС ? если точность при н.у. +/- 10 метров ?
в теории да: через компл. фильтр, либо калман… в крутых контроллерах типа немец, наза, а также от vis.asta так и сделано… он иногда по капле открывает секреты 😃
чем точнее (и дороже соот-но) аксель, тем меньше можно брать степень корректировки, чтобы не вывалится из стабилизации интеграторов… он кстати, про mpu6050 (который мы тут так хвалим и радуемся) отзывался как про унылое ггг 😃 … каждой задаче своя цена как грится…
upd: вчера написал первую версию аксель+гпс 😃
как распогАдится, пойду тестить!