Создание собственной системы стабилизации
вот я тут makefile поломал, ну и как искренне русский теперь бы инструкцию почитать, как они вообще делаются 😃
Качество стабилизации , по моему , основная задача а оно зависит в первую очередь от частоты опросы ДУСа, аксель всеравно 50-ти герцовый фактически. Хочу как раз у себя попробовать (этож экперимент!) основноу приоритет отдать ДУСу, а остальные подождут…
Чтение датчиков занимает кучу времени. Делать это в прерывании - не самая хорошая идея, имхо.
Тем более что ты все равно с ДУСа будешь иметь нектороый шум, который еще надо отфильтровать, и частота у тебя сама собой упадет.
Тут больше важно иметь все показания со всех датчиков одномоментно, то есть производить обноваление показаний с единой частотой для всех датчиков, допустим те же 50Гц.
вот я тут makefile поломал, ну и как искренне русский теперь бы инструкцию почитать, как они вообще делаются 😃
А от чего make ? На чем “сидишь” ?
eclipse gcc Cygwin+maple
- не самая хорошая идея
Это как раз все надо пробовать, “поиграть” -так сказать, все остальное и так как в известных готовых проектах, ограничено “железом”.
Это как раз все надо пробовать, “поиграть” -так сказать, все остальное и так как в известных готовых проектах, ограничено “железом”.
Ну чтож, тогда будет очень любопытно узнать результаты.
eclipse gcc Cygwin+maple
Ууу, ядерная смесь! 😃
Увы, не подскажу, сам на IAR и VisualStudio.
Качество стабилизации , по моему , основная задача а оно зависит в первую очередь от частоты опросы ДУСа
Вы меня не поняли. Читать значения акселя, надо с той частотой, на которую вы его настроили (ну если мы говорим о цифровом сенсоре). Только читать не обязательно сию минуту как пришло прерывание от него, у вас есть время это сделать до следующего прерывания.
Вот примерный алгоритм главного цикла программы
loop {
if (Gyro_ready) {
Read_gyro_data;
new_data_received = true;
}
if (accel_ready) {
Read_accel_data;
new_data_received = true;
}
if (new_data_received) {
Update_DCM; // Обновление алгоритма стабилизации DCM, MARG, CF, EKF ну или что у вас там
Set_Output_PWM; // Выставляем новые значения PWM на моторы
}
... другая работа что у нас еще осталась, например отправить телеметрию
}
Суть сего в том, что в прерывании от Гиры, вы выставляете флаг Gyro_ready и все. Прерывание занимает пару микросекунд времени, в итоге даже если прерывание от гиры, попадет на прерывание от Приемника, вы потеряете пару-тройку микросекунд, что при длине импульса PWM от 1000 до 2000мкс - практически - ничто.
Компилер CodeSourcery ARM EABI (2011.09-69)
это есть, ааа сейчас попробую пересобрать, кажется догнал в чём беда…
No rule to make target `objSTM32/dummy/../AeroQuad32/AeroQuadMain.elf', needed by `elf'. Stop.
нет правила для сборки, блин где ж его найти, патчи настроены всё видится, чего-то ещё не хватает, затык был сначала тут:
LIB_MAPLE_HOME = …/Libmaple/libmaple
убрал лишнюю точку - всё увиделось LIB_MAPLE_HOME = ./Libmaple/libmaple
проверте пожалуйста
сам и проверил на работе всё нормально…
Компилятор начал подавать признаки жизни, но что-то не так 😦
**** Build of configuration Default for project AeroQuad ****
make all
Compiling C: AeroQuad32/MapleCompatibility/flash_stm32.c
Compiling C++: AeroQuad32/AeroQuadMain.cpp
Compiling C++: AeroQuad32/MapleCompatibility/EEPROM.cpp
Compiling C++: Libraries/AQ_I2C/Device_I2C.cpp
Compiling C++: Libraries/AQ_Math/AQMath.cpp
Creating library: Libmaple/libmaple/libmaple.a
arm-none-eabi-ar rcs Libmaple/libmaple/libmaple.a objSTM32/dummy/./AeroQuad32/MapleCompatibility/flash_stm32.o objSTM32/dummy/./AeroQuad32/AeroQuadMain.o objSTM32/dummy/./AeroQuad32/MapleCompatibility/EEPROM.o objSTM32/dummy/./Libraries/AQ_I2C/Device_I2C.o objSTM32/dummy/./Libraries/AQ_Math/AQMath.o
Linking: objSTM32/dummy/./AeroQuad32/AeroQuadMain.elf
arm-none-eabi-gcc: ./Libmaple/libmaple/libmaple/syscalls.o: No such file or directory
rm Libmaple/libmaple/libmaple.a
make: *** [objSTM32/dummy/./AeroQuad32/AeroQuadMain.elf] Error 1
**** Build Finished ****
попробуй либы компильнуть отдельно make -C Libmaple/libmaple library компилится?
сейчас не могу
./Libmaple/libmaple/libmaple/syscalls.с - фаил есть
может здесь Creating library: Libmaple/libmaple/libmaple.a ещё каталог libmaple нужен?
так Libmaple/libmaple/libmaple/libmaple.a ?
к этим
Device_I2C.cpp из ./Libmaple/libmaple/libmaple/ библиотеки цепляются…
может здесь Creating library: Libmaple/libmaple/libmaple.a ещё каталог libmaple нужен?
Не нужен
Device_I2C.cpp из ./Libmaple/libmaple/libmaple/ библиотеки цепляются…
По-моему для компиляции Device_i2C из ./Libmaple/libmaple/libmaple ничего не линкуется
может и не к нему, вечером точно посмотрю…
Чтение датчиков занимает кучу времени. Делать это в прерывании - не самая хорошая идея, имхо.
А вы с какой частотой опрашиваете ШИМ с приемника? И с какой гиро и аксель?
А вы с какой частотой опрашиваете ШИМ с приемника? И с какой гиро и аксель?
Гиру и аксель с максимальной планирую. Данные забирать на обработку по готовности. Пока ни с какой. Но так то каждый цикл желательно. Например, если в МультиВий время цикла 3000 мкс, то получается частота 33Гц примерно.
А ШИМ поступает с приемника с частотой 50Гц. Обрабатывать планирую не чаще 5 Гц. Хотя тоже надо пробовать, как будет сказываться на управлении.
то получается частота 33Гц примерно.
Не 33, а 333Гц
А ШИМ поступает с приемника с частотой 50Гц. Обрабатывать планирую не чаще 5 Гц. Хотя тоже надо пробовать, как будет сказываться на управлении.
я посчитал, с какой скоростью я дергаю стики на 3D самоле, получилось примерно полный размах стика, (от 1мс до 2 мс) проходит где-то за 0,2с. т.е. получается я дергаю стиком с частотой 5Гц в пике. т.е. если опрашивать приемник реже 5 раз в секунду, то можно просто не успеть за стиком. Кароче, сейчас у меня сделано именно опрос приемника с частотой 5Гц, каждые 0.2с, и это очень, очень плохо. машинка вообще не успевает отработать все движения стика.
я думаю надо с максимальной, с частотой самого приемника шим мерить и выдавать наружу. Кто как думает? у кого как сделано?
Не 33, а 333Гц
Да, все верно, с телефона писал, пропустил цифру.
я посчитал, с какой скоростью я дергаю стики на 3D самоле, получилось примерно полный размах стика, (от 1мс до 2 мс) проходит где-то за 0,2с. т.е. получается я дергаю стиком с частотой 5Гц в пике. т.е. если опрашивать приемник реже 5 раз в секунду, то можно просто не успеть за стиком. Кароче, сейчас у меня сделано именно опрос приемника с частотой 5Гц, каждые 0.2с, и это очень, очень плохо. машинка вообще не успевает отработать все движения стика.
я думаю надо с максимальной, с частотой самого приемника шим мерить и выдавать наружу. Кто как думает? у кого как сделано?
Вы на самолет воздействуете напрямую, или через систему стабилизации ?
Вы на самолет воздействуете напрямую, или через систему стабилизации ?
напрямую. а какая разница? плата стабилизации это как бы проходная плата, которая при необходимости может самостоятельно вносить коррективы на рули управления. а когда такой необходимости нет, она должна полностью повторять сигнал с приемника, в том числе и скорость его изменения
RUNTIMELIB = $(LIB_MAPLE_HOME)/build/libmaple.a не создаётся библиотека - где копать?
опля, в libmaple ешё один проект который и создаёт то, что надо - он компилится, дальше опять танцы с бубном…
Для Geniok и Alexsis1109: Коллеги, я что-то пропустил ) АВР я рассматривать не буду, ибо там нужно действительно делать много приседаний для сохранения нормального темпа работы всей системы.
Если берём СТМ32, то о чём собсно речь?
Считаю свою систему:
Частоты
ДУС - 380Гц
Аксель и магнитометр - 50Гц ,
ППМ (разделённый по каналам, т.е. 4 канальный захват ШИМ) примерно 60 Гц,
всё остальное имеет приорететы ниже и выполняется по освобождению.
Итак: для 103го СТМа (без аппаратной плавучки):
- Петля ДУС, выполняется: чтение ДУС, обновление текущего положения в пространстве, вычисление ошибки положения относительно заданного
период ДУС 1/380 = 2.6 мсек, максмальное время обсчёта ~0.3 мсек: заполнение машвремени цикле ~11%. - Петля акселя, выполняется: чтение акселя, обновление ошибки для коррекции текущего положения по ДУСу, интегрирование линейной скорости по акселю, запуск чтения магнитометра.
период акселя 1/50 = 20 мсек, макс.время обсчёта ~0.35 мсек, заполнение машвремени в цикле ~2%. - Петля ППМ, выполняется изменение настройки таймера на отлов фронта\спада, вычисление длины импульса ППМ, вычисление задающего кватерниона. Период 1/60 = 17мсек, макс время обсчёта 0.12 мсек, заполнение ~1.4%.
В наихудшем случае, если все эти события произойдут одновременно и будут обработаны сверху вниз в порядке приоритета, то получим 0.3+0.35+0.12 = 0.77 мсек или ~30% от минимального цикла системы (периода ДУС)!
И при этом заведомо понятно, что в следующем периоде ДУС других событий не будет (кроме собственно обработки ДУС). А для Ф3 на той же частоте время выполнения делим примерно на 10. Дык стоит париться всё это высчитывая?
Главное не тупить в пустых циклах в ожидании событий, у СТМа всё для этого есть.
И ещё один момент, проценты показвают загрузку до потолка, но потолок это не 100% ❗, а 200 😈 Вот почему, то что мы не уложились в мин цикл системы (100%) это конечно плохо (сбивает регулярость системы), но вобщем ничего фатального, главное чтоб обработчик собственно ДУСа успел отработать, а недоработавший обработчик с низким приоритетом(например акселя) он прирвёт и ещё раз обновит данные о положении, после чего аксель досчитается и отдаст проц обработчику ППМ. Но это всё будет работать если такие ситуации в системе достаточно редки (например если приемник дал помеху с более высокой частотой), т.к. недообработанным прерываниям необходимо досчитаться в течении следующих периодов, до наступления собствеенного прерывающего события.